Also, as you can see, I cannot write at (a) in the Qt browser. For some reason the alt modifier has stopped working. Also there are other local problems with the Danish keymap: You cannot add a diaeresis (umlaut) to letters, or a grave or acute (i think they are called), because I am using RAWKEY input. I think I have to restructure the keyboard input code completely and do both RAWKEY and VANILLAKEY input. Thanks to Olaf Barthel for pointing out this solution.
The tab problem you are mentioning has to do with me reimplementing the mouse key handling. Sometimes, when you single click a single item twice (tab bars are interpreted as a single object, even when clicking different tabs), the single click events would be overrulled by the double click event. This is now fixed.
Also popup (as in menus) handling should be a lot better now.
Awesome, step by step we are getting closer to a perfect implementation !
Before you will be annoyed enough please let me to remember other 2
Quote:
4) - Double Focus on an input text: Try for example to open two separate Qt windows that contain an input type, for example Calculator You will see that the area when you can entering a number will got the focus (cursor active and blinking) on both windows rathen then only on the one selected
This one doesn't seems a big issue, however would be cool if you can fix
Quote:
5) - As you know still the usual autoalign crap on windows and sometimes some graphical glitch when you try to reduce a window at a minimal size .. this second problem is not always visible, it mostly depens on what demo/example you are testing
I annoy you with this one many time i know, however during other test in various Qt programs i observe that this specific problem is not visible at all, for example the about window of MuseScore or ScreenGrab (that indeed like others they are normal popup windows) will be opened perfectly, fast and without any autoalign crap .. so i though, maybe you can use the same solution for any other type of windows ?
Same thing about glitch during resize, altrough here i think you can't use the same solution for any tipe of windows around ..
alfkil wrote: About URLs, I am not sure how to do it differently? Of course I could insert yet-another option in qtprefs. Or is there a more system compliant way?
Yes - check out launch-handler. Basically if you open "URL:http://www.amigans.net" (and then close it again immediately) that will ask which browser to use from URL prefs, and open that URL.
Quote:
Also, as you can see, I cannot write at (a) in the Qt browser. For some reason the alt modifier has stopped working. Also there are other local problems with the Danish keymap: You cannot add a diaeresis (umlaut) to letters, or a grave or acute (i think they are called), because I am using RAWKEY input. I think I have to restructure the keyboard input code completely and do both RAWKEY and VANILLAKEY input. Thanks to Olaf Barthel for pointing out this solution.
Hmm... I'm not sure that's right. I use RAWKEY only in NetSurf and dead keys, qualified keys, etc, work just fine. I basically just use MapRawKey, but if you search for ami_key_to_nskey in amiga/gui.c you'll see exactly how it works. I keep track of the qualifiers too, but only for uses other than text input.
4) - Double Focus on an input text: Try for example to open two separate Qt windows that contain an input type, for example Calculator<br>You will see that the area when you can entering a number will got the focus (cursor active and blinking) on both windows rathen then only on the one selected
Those are two separate apps, and there is no way I can make a global (accross apps) focus widget. Sorry.
@samo79: Auto align is troublesome. The X11 code, that I have used as a model for the amiga version is quite complex and pretty incomprehensible in this area. I am guessing this should be much less troublesome in Qt 5 (hoping hoping), and thus I am not going to spend a lot of time with it.
Those are two separate apps, and there is no way I can make a global (accross apps) focus widget. Sorry.
Well, mine was just an example and honestly not the best if i think more about, in reality we can see the same problem also with a single window
I'm not a coder at all but I think you may just "disabled" the cursor once the window will be unselected and then re-active the cursor again when the user click again on that window
At the end it's just a very basic behaviour common on any framework around, including Qt on other platforms or MUI/Reaction on Amiga
Chris: Do I remember that you have checked Calligra suite sources already? Now QT starts to be usefull and Calligra is at least advertiset to be "relatively easy to port", would it be possible to implement?
utri007 wrote: Chris: Do I remember that you have checked Calligra suite sources already?
Nope, not me, but I've had a look at the build instructions (far more difficult to find than they should be), and it appears to need kdelibs - Qt alone is not enough.
@samo79 You mention Arora and stability. Well, the stability issues (or rather just bugs) in the current Qt browser come from libQtWebKit, and thus a port of Arora would have exactly the same issues.
About auto align "crap": I figured out, that the problem is in intuition. I have delayed the showing of windows until the autoalign has happened. But sadly, when trying to resize a hidden window, it is automatically showed on screen... Doh! I think I can cook up a solution, though.
Quote:
Calligra
Calligra needs A LOT more modules than just Qt and KDE. Most of them are probably pretty easy to port (I have done some already (untested)), but the sheer amount of code that has to be processed makes it quite impossible for me to go into it at the moment. Also it seems to need libQtDbus, which we don't have in the current Qt port.
You mention Arora and stability. Well, the stability issues (or rather just bugs) in the current Qt browser come from libQtWebKit, and thus a port of Arora would have exactly the same issues.
Ah ok then, I realized that the problem was only into the included test browser, not that the entire libQtWebKit needs some more love
Quote:
About auto align "crap": I figured out, that the problem is in intuition. I have delayed the showing of windows until the autoalign has happened. But sadly, when trying to resize a hidden window, it is automatically showed on screen... Doh! I think I can cook up a solution, though.
Thanks Alfkil Sometimes ago i open a thread on the Hyperion forum and more or less the result of the discussion was that the best thing is to implement the necessary fix directly on the third parties software (in this case Qt) rather than Intuition
Personally i have noticed that this auto-align issue does not occur with any types of windows, for example the "About Qt..." window suffer of this problem and it's not the only one, but other Qt's windows not (the about window of MuseScore is ok for example)
Perhaps you could use the same code of that specific "good" window as a basis for any other windows of the framework ?
1- Flick client (Started from qtdemo) always crashed when you try to close it with ESC
Quote:
Crash log for task "" Generated by GrimReaper 53.5 Crash occured in module at address 0x4F9149EC Type of crash: ISI (Instruction Storage Interrupt) exception
The problem is, that those apps, that do not suffer from this behavior, are those that explicitly sets the widget size *before* creation (for instance in the constructor you will see something like this: "mywidget->resize(blabla);"). The apps that suffer from "auto-align crap" all rely on automatic alignment to determine the size and position of the widgets. Also I found out, that the problem is not, that the showing of widgets come at the wrong time, the problem is (simply put), that intuition has weird behavior with hidden windows: When actually showing a hidden window, intuition will first create a window with the *original* size and position and then right after it will "auto align" it to the *actual* (new) size and position. In my eyes it looks like a bug, but I will probably have trouble convincing system devs of this view...