I'd suggest making the Intuition sizing gadget appear in favour of the Qt one
I share this, even because by default a lot of programs still without their resize gadget now --> QtWeb just to mention one
I will mantain the Intuition resize gadget by default and only optionally (or dinamically when needed) the internal Qt resizer
@Alfkil
Quote:
Ok, this is hopefully the last quickfix before a proper release:
Mate this update is a huge step forward for what i can see, menu still stealing the focus, but they now no longer "block" the interface so finally all become quite usable, aka the integration is nearly done now
Quote:
Try deleting envarv:qt.prefs and try again. Then send screenshot.
Mmm i deleted the qt.prefs in ENVARC but i didn't found the resize method you mention, i have only that:
whilst you're doing QuickFixes, can you please remove the nonsense keyboard shortcuts from the native menus? they don't work, and often you end up with a menu full of entries with shortcuts that are all the same (see my earlier screenshot here)
Menu shortcuts: That is odd... I think I am just doing a translation of the shortcut connected to the specific QAction. And as to why the shown shortcuts don't work, I am a little confused. Is that intuitions fault or mine? Are menu shortcuts handled automatically, or do I need to actually write code for implementing them?
Could you give an example of an app, that has multiple instances of the same menu shortcut? I am using RMBTRAP, so that is probably the reason for the shortcuts not working. Actually, shortcuts are handled by Qt internally. What I have done in the native menu code is to translate all instances of ctrl into right amiga, so it shows up with a nive icon image in the menu. If you try opening qt:examples/mainwindows/application, you will see, that ctrl+x always works as 'cut'. RAmiga+X also works as cut, if the mouse is placed outside the window, but not inside. This can be remedied by choosing the middle mouse=context menu from qtprefs; this will prevent the use of RMBTRAP. I am not sure how to do this better. Would it be better to maybe keep the ctrl+x specification in the native menu?
Well, I just took another look at your screengrab, and indeed there is a plurality of samelooking shortcuts. Ich will investigieren!
Would it be better to maybe keep the ctrl+x specification in the native menu?
If that works all the time and won't cause duplicates, then yes - it probably is better to put that shortcut in the menu.
It would be nice to have RAmiga-shortcuts though... hmm, is it possible to create menus in Qt with a shortcut which uses RAmiga? If so, a little bit of editing of the menus before releasing a Qt app would resolve this problem!
Sadly Quickfix 7 broke my ported application QRule - the Qt window style hint "Qt::FramelessWindowHint" doesn't work properly anymore! It now features always a top bar, which it definitely shouldn't!!!
About iconification i've found another strange bug introduced since QuickFix 5 (or 6 ?)
When you de-iconify an iconified program (even if only the main window was opened before you have iconify it) all the previews contents you have opened in whole session (windows or menus) will be re-showed all togheter on screen again !
An example:
1 - Start QtWeb and open the prefs window 2 - Close the prefs window normally 3 - Open the about program window 4 - Now iconify QtWeb using the iconify gadget of the about window (this will iconify all the program windows --> OK) 5 - Deiconify --> this should reopen on screen the program window and the about window only --> anf it's ok, but it will reopen also all the windows/menus you have opened on the entire session, so also the closed things !
Another example:
Doing the same thing (but without opening the prefs window) --> now after a deiconify the program menu will be showed opened aswell, see grab:
About blending modes: Well, those should already work with software rendering. If you try the demos/composition demo, you should see what I mean (you probably need to rebuild that one because of an obsolete symbol). I am a little reluctant to implement blending modes with compositing, because there are so many things to take into account (I would need to implement it into every single paintning function) and also because there is not support for every kind of mode in the compositor (which would probably mean writing custom code directly in QPainter, which is something I would rather avoid unless really necessary). For your purpose, ie. highlighting a small piece of text, the software blending should be fast enough. Or is the problem, that it doesn't work at all?
EDIT: About native menus: Apparently the NewMenu structure only supports RAmiga+key as shortcut. The reason you see many instances of RAmiga+S is, that I have forgotten to interpret (remove) the 'Shift+' from the string, and so the S is interpreted as the key to use for the shortcut. I can of course remove the 'Shift+' string, but what you get is then the wrong shortcuts and more possibilities for duplicates. The whole thing is a little convoluted, and I am not sure I want to spend excessive amounts of time on it. If someone has an ingenious solution, I would be more than happy to know.
alfkil wrote: For your purpose, ie. highlighting a small piece of text, the software blending should be fast enough. Or is the problem, that it doesn't work at all?
It doesn't work at all - it just outputs an error something like "blend mode not supported".
Anyway, there seems to be a distiction between PorterDuff modes, which are those currently supported by CompositeTags, and BlendModes, which are those not supported (including Multiply). I would be able to implement the PorterDuff modes, but not the BlendModes.
EDIT: Well, actually, since I am already mentally involved here, I could of course implement the above scetched solution as a default fallback for any function wishing to use blending. It would require some work, though...
- PorterDuff compositing modes for HW render mode (experimental, still some problems) - Frameless windows work again - Removed "Shift+" from native menu shortcuts (would just be interpreted as RAmiga+S) - Included qtprefs app ('Qt') - Reads the app name from wbStartup message - Fixed iconify (now hidden windows are not uniconified, icon shows app icon and app name) - Screen title now bears the name of the app (can be changed with qApp->setApplicationName()) - Handles local charsets for SysTray messages
So MULTIPLY is MULTIPLY DstA= SrcA * DstA DstC= SrcC * DstC; A=Alpha C=Color But MULTIPLY dont exist in os4-compositing MULTIPLY exists in Warp3D/MiniGL but they use W3D_texture not bitmap :-/
Can do that to highlight something : COMPOSITE_Src_Over_Dest with an alpha set to 0.5 or less will do DstC= SrcC*0.5+ DstC*0.5;
Alain Thellier - Wazp3D
Edit: if source contain an uniform RGB color a better approximation is A=(R+G+B)/3;