Fine one , but also a bit slow, cursor a bit fucks to detect what it mean , and as usuall after some usage on public minigl/warp3d trashing of textures :)
No support national keymap. No support (Amiga + c, amiga +v). Requester no support Amiga partitions.
1) SPEED [WAIT FOR GALLIUM AND MESA] The cause of most of the "slowness" is, that Qt relies on framebuffer objects when drawing to QPixmap's. MiniGL doesn't support FBO's, but MESA does, so the most sensible way to deal with this problem is to wait for GALLIUM and MESA.
2) Trashed text rendering [HELP NEEDED] This is because of an api "discrepancy" in minigl. I need to look at the minigl sources again to see, if I can fix it.
3) Trashed textures [WAIT FOR WARP3D] As far as I know, this has already been fixed in Warp3D, correct?
4) Submenu close too early [CHECK] Yeah, bummer, should be easy to fix
5) Cursor problems [CHECK] Again should be easy to fix
6) Keymap problems [HELP NEEDED] I need to know the rawkey codes for different local keymaps to fix this. Is it possible to find those anywhere?
7) Control alt amiga not implemented [CHECK] This should be easy to fix
8) Spawning windows at entry [IS IT OK NOW?] I have no idea, why this happens, but I will try and fix it
9) Animated tiles doesn't exit properly [CHECK] I sort of know why this happens, but not how to solve it. If it turns out to be wildly complicated, I will not fix it, because it is the only app with this problem.
10) Drag'n'drop crash [CHECK] Drag and drop is not completely finished. I will try to fix this.
11) Colliding mice crash [CHECK] I have no idea why this happens, but I will try and fix it.
12) Drag and drop flickering [CHECK] The reason it flickers is, that I need to close the drag window temporarily to detect which window is underneath. The only way to fix this is by somehow being able to detect the _second_ layer at a given point. I don't know how to do this. Help!
13) Native (asl) requesters [CHECK] This should be possible
14) Native menus Not so good... Gadtools can only create one sublevel of menus, while Qt can handle infinite sublevels. I could make it optional (by means of a env variable), but this is definetely not my first priority.
15) Public Screen [CHECK] I will create an env variable to facilitate showing Qt on a given public screen. Almost already implemented.
16) Double click not implemented [CHECK] Should be "easy" to fix.
17) Native Reaction or MUI theme This is a "far-out-in-the-future" thing.
18) Installation script Currently I have no experience with this, so I will need to learn how to do it first.
Ok, that was my list. Any more suggestions and comments are welcome!
Edited by alfkil on 2011/4/29 0:06:27 Edited by alfkil on 2011/4/29 14:35:13 Edited by alfkil on 2011/4/29 21:28:09 Edited by alfkil on 2011/4/30 19:54:08 Edited by alfkil on 2011/5/2 18:44:46 Edited by alfkil on 2011/5/3 13:41:18 Edited by alfkil on 2011/5/3 17:59:29 Edited by alfkil on 2011/5/3 20:01:46 Edited by alfkil on 2011/5/3 20:04:02 Edited by alfkil on 2011/5/3 20:07:58 Edited by alfkil on 2011/5/3 20:24:42 Edited by alfkil on 2011/5/3 20:51:37 Edited by alfkil on 2011/5/3 20:53:50
1) SPEED This is of course the most wanted feature, but sadly also the hardest to do. Really, the Qt screen update system is very complex, and there is not a lot I can do without trashing the whole system. I know only one thing, that I can readily do: The translation btw QImage and QPixmap is implemented by me and is very slow (uses pixel by pixel translation). I shold be able to do smth with p96WritePixelArray or smth. For everything else, I think the best bet is to wait for the release of Gallium and hope, that this will bring us more speed.
Interesting moment that first versions was pretty fast. I mean those EmbeddedDialogs demo was buggy, but was fast. Now they not buggy, but slow. As i understand it happens or because you add OpenGL to all the functions (but before there was raw cpu calculation) , or maybe its indeed that "QImage and QPixmap translation" ? Or in that example its not involved ?
Did that "QImage and QPixmap translation" involved with menus ? Or its just something with working are only ?
Quote:
3) Trashed textures As far as I know, this has already been fixed in Warp3D, correct?
As i know - yes. If you not have that trashing on your beta-system, then yep, it was fixed , just not released as usuall :)
Quote:
14) Native menus Not so good... Gadtools can only create one sublevel of menus, while Qt can handle infinite sublevels. I could make it optional (by means of a env variable), but this is definetely not my first priority.
I not so know all that gadtools/boopsi/reaction stuff, but did it possible to use reaction for making the same native menus with all that infinite sublevels ?
Why i think its important: because when menu is native , its reacts very fast, and feels very good. Sadly that i can't do the same for LodePaint, and because of it, LodePaint menu the same slow as menus of QT. But if i can someday, for sure i will change all the opengl menus on the reaction ones. Even if our native menus will be limited somehow in compare with original QT ones, i still think many users will choice limited one, just because of it speed and reacts.
Quote:
Any more suggestions and comments are welcome!
Some more :)
-- Callback for font-generation of first running of QT , to show users that is font-generation happens (or, somehow get rid off from fontconfig at all)
-- Remove that example which crashes on exit and which you dunno how to fix for the final release
-- Remove debug output, add -03, do stripping, etc for final release (to make all loads/works faster, and have smaller bins)
-- Native os4 look (but that is very last priority i think, for the very final end, and even can be done not by you, but by someone else). But if you put it in your todo list, then it will be even better :)
6) Keymap problems I need to know the rawkey codes for different local keymaps to fix this. Is it possible to find those anywhere?
The InputEvent gives you the rawkey codes, and are translated to actual characters using MapRawKey.
Rawkey codes are the same for all keymaps, they just map to a different character. How is it implemented in Qt?
Quote:
12) Drag and drop flickering The reason it flickers is, that I need to close the drag window temporarily to detect which window is underneath. The only way to fix this is by somehow being able to detect the _second_ layer at a given point. I don't know how to do this. Help!
Do struct Layer's front and back pointers contains the layer immediately in front or behind the layer you are looking at?
Quote:
Any more suggestions and comments are welcome!
I keep finding things expecting QDesktopServices, will that be implemented?
@kas1e
Quote:
I not so know all that gadtools/boopsi/reaction stuff, but did it possible to use reaction for making the same native menus with all that infinite sublevels ?
No, Intuition itself is limited to single submenus (99% of the time this is enough, cascading further than that is usually annoying for the user)
Quote:
Why i think its important: because when menu is native , its reacts very fast, and feels very good. Sadly that i can't do the same for LodePaint, and because of it, LodePaint menu the same slow as menus of QT. But if i can someday, for sure i will change all the opengl menus on the reaction ones. Even if our native menus will be limited somehow in compare with original QT ones, i still think many users will choice limited one, just because of it speed and reacts.
I agree, and the majority of applications probably only have one level of subitems anyway. Anybody porting Qt apps to the Amiga should be aware of this limitation and be able to modify the code, so I don't see a big issue with only allowing proper Amiga menus.
I agree, and the majority of applications probably only have one level of subitems anyway. Anybody porting Qt apps to the Amiga should be aware of this limitation and be able to modify the code, so I don't see a big issue with only allowing proper Amiga menus.
Yep, but after some tests with menus today, i think that will be a bit bad to remove QT menus at all (they are good looking (just slow) ), and will be a bit sucky to replace it fully for all the time by reaction ones (because someday gallium/mesa will be released, and so we can use it with normal speed).
Imho as Alfkil say, will be cool to have "env" , like "native/qt", and it will good in all the ways:
-- users with slow machines (sam440, old a1, or even classics), will just use "native" one , and it will be fast and good for them (so, more porters and users in end).
-- while we have sucky opengl implementation, we also can use "native" (just because gallium/mesa can take years, but we can already start porting the most necessary and fancy apps, as well as use it already too)
And to docs just add something like:
Quote:
Beware ! If you will use Native menus, it will be limited by intuition to the one sub-level. But because in 99% menus are plain , or just with one sub-level, its all not problematic should be for porters.
Because QT will bring for us tons of new (and big) apps, all of that "native" changes for sure will be worth of it (if only alfkil will have energy and motivation:) )
@alfkil While we talk about all that replacements, i found that buttons, labels, drop-down menus an alt a bit slow as well. Sure its opengl-speed problem, but maybe will be also not bad idea to change buttons/lables/dropdown menus also on reaction ones (when user will set that ENV to use native stuff).
Sure its all pretty hard, but maybe for todo-someday-somehow :)
14) Native menus Not so good... Gadtools can only create one sublevel of menus, while Qt can handle infinite sublevels. I could make it optional (by means of a env variable), but this is definetely not my first priority.
Well, Chris said that Intuition is limited to single submenus only (so the same problem should be also on our Firefox 4.0 port almost with the current OS4 release!)
The solution i think can be to try to working side by side with the OS4 mantainer of this part and add multiple menu support on AmigaOS 4.1 Update 3 first .... if not in the future it would be problematic to build real applications with such QT interface :-/
The InputEvent gives you the rawkey codes, and are translated to actual characters using MapRawKey.
... or you can get the rawkeys from your IDCMPMessage, should be the same. (And yes, I use MapRawKey).
Quote:
Rawkey codes are the same for all keymaps, they just map to a different character. How is it implemented in Qt?
... but my danish keys work just fine, which _must_ mean, that the ex. polish keys have different rawkey codes, or?... I have implemented every key on my own keyboard (except qualifier keys).
... but my danish keys work just fine, which _must_ mean, that the ex. polish keys have different rawkey codes, or?... I have implemented every key on my own keyboard (except qualifier keys).
If you have a look through the OS4 keymap files, there is a diagram of the keyboard with the codes marked. There are slight differences between real Amiga keyboards and PC keyboards.
Other than that the special keys are documented in one of the includes (something like devices/keymap.h or libraries/keymap.h).
If you are using MapRawKey then you shouldn't need to worry about this anyway.
Yep, but after some tests with menus today, i think that will be a bit bad to remove QT menus at all (they are good looking (just slow) ), and will be a bit sucky to replace it fully for all the time by reaction ones (because someday gallium/mesa will be released, and so we can use it with normal speed).
The speed isn't the issue, the non-standard user interface is.
The env-var is a good compromise, but using Inuition menus should be the default.
As samo79 says, it would be good if the OS4 devs could update Intuition to support more sub-item levels. The structure doesn't inherently forbid it - I see no reason why submenu MenuItem structures can't also utilise SubItem to cascade to another level, it's just Intuition doesn't recognise this as valid. The NewMenu structure etc would need udpating too.
Whilst they are there they can check if image menu items work, as I can't get anything out of them
If you have a look through the OS4 keymap files, there is a diagram of the keyboard with the codes marked. There are slight differences between real Amiga keyboards and PC keyboards.
Other than that the special keys are documented in one of the includes (something like devices/keymap.h or libraries/keymap.h).
Also check out Documentation/Keyboards.doc and Documentation/Keymaps.doc.
The mystery is solved: The lack of framebuffer objects in minigl is the cause of the slowness. Basically what happens is, that every time something happens that involves painting on a QPixmap, the system switches over to the "raster" painting engine - which basically means CPU painting. One of the following things could happen now:
a) I implement framebuffer objects in minigl b) I reimplement the pixmap paint engine without use of frame buffers c) I wait for Gallium and MESA
a) and b) might be just too much work compared to the gains - if they are even possible at all. I think I will go for c) (sorry).
it would be good if the OS4 devs could update Intuition to support more sub-item levels. The structure doesn't inherently forbid it - I see no reason why submenu MenuItem structures can't also utilise SubItem to cascade to another level, it's just Intuition doesn't recognise this as valid. The NewMenu structure etc would need udpating too.
The problem is that MenuNumber is defined as a 16-bit number, and this only has space for one level of SubItems. If it were possible to switch to 32-bits without breaking compatibility, then this wouldn't be an issue, but as I don't think that's possible, you might as well just rewrite the menu system from scratch...
From a quick check, here are some places that MenuNumber occurs: MenuItem->NextSelect (is a UWORD) IntuiMessage->Code (is a UWORD) ItemAddress(..., UWORD MenuNumber)
a) and b) might be just too much work compared to the gains - if they are even possible at all. I think I will go for c) (sorry).
There is still plenty thinks in your todo-list, so when all of this will be done, maybe galiium will come :) At last Hanz on his blog write that he will concetrate on 3d now, what mean that they with Rogue will works on it (so all should be faster).
alfkil, how about integrating the qt sdk into the os4 sdk? i find it odd to have it at a totally different location, i mean it's "just" a lib and should be installed as such in the os4 sdk? or am i missing something? how should this be installed?
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
