About the native menus, then I have to say, that this is the way it's going to work: When pressing right mouse inside the window, you will trigger a right mouse button event. When outside window, you will trigger the native menu. This is the only way I can do it, as long as you want both right mouse events (eg. context menus) and native menus at the same time, since there is no flag to tell me, if the selected widget wants right mouse or nothing.
How about checking whether the mouse is over a widget, then seeting RMB_TRAP if so, also allow system menus to appear when the mouse is over the borders, (you might have allready done that) so that full screen windows can get their menus. Having to move move the mouse more than is necessary to move get at the menus is not ergonomic.
A menu qualifier key is also an option but not very "amigaish"
Since everything in Qt is a widget (including windows), it really makes no sence to check if the mouse is over one, better to check, if the mouse is inside a window, which is what I'm doing now.
The only solution I see, if users want both context menus and native menus over widgets, is to use the middle button as a substitute.
I smell there is new QT release is coming with fixes and new SDK for play with :)
Alfkil, its is possible that this LockPubScreen problem also used in all the other examples, and because of which , EmbeddedDialogs or even your Designer port are slow ? Maybe even EasyPaint and ColorCode ports was slow because of the same ?
Btw, did you have some very old-first versions of QT , where you first time make EmbeddedDialogs works ? I mean you can check the speed of it, and the current one, and it will be a start to found the problem.
A new release is in the works, yes. Probably tomorrow or so.
About slowness, I will of course double check the code to see if the embedded dialogs example could be harmed by some pub screen locking, but I'm thinking no, it is probably not that which is slowing it down. I only have the latest release stored on my hd, so it is not possible to test without rolling back all my code to a former release.
The only solution I see, if users want both context menus and native menus over widgets, is to use the middle button as a substitute.
Would it be possible for the user to disable context-menus (and so enable normal menus over window) on a per-program basis? Not all programs will need context menus.
You have some (small) typos in the installer script: "Welcome to installing AmiCygnix-base" <- That one is on the 2nd page where the user selects his skill level (the 1st one is fine)
"AmiCygnix-base is installed to ..."
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
Ok installed latest version 0.8.1 and i note a few issues:
It seems we completely miss "libintl.so" from the QT archive and examples doesn't start without it (lots of annoying requesters), so i download this library from OS4Depot and i copied it into SOBjs main dir, now QT works
Other problems:
- Examples/network/downloadmanager (don't work)
Quote:
socketSignalMask = 0x4000000 QProcessPrivate::initializeProcessManager() QProcessPrivate::initializeProcessManager() END ASSERT: "!isEmpty()" in file /qt/include/QtCore/../../src/corelib/tools/qlist.h, line 269
@alfkil Installed latest user and sdk archive, and that what i found:
Problems/bugs:
-- on running all QT apps ask for Cygnix: assign -- in QT prefs cant found anything about MIDDLE button, that how looks like my new QT prefs:
-- usuall problems with speed , and Designer indeed slow (but still, with all those native menus its looks very good :) , with normal speed that all will rokz hard !)
Cool moments:
-- That draggableicons example never crashes for now. All works fine, yes ! -- Whole project now feels professional and pretty polished (speed problems a bit broken fan of course, but as you say you will try to worry about, so fingers on the cross). -- Recompiling of all the programs with new sdk/new user archive did the trick , and all those small shity ports which i do works fine.
Ideas to improve:
-- in QT prefs : "ESC = close gadget" (can be usefull)
But in general, all what is important now, its somehow understand why Desinger much slower natively in compare with ACygnix one, and i think that it will automatically speedup all the other programms. Maybe its all even not because of minigl, but just something like the same LockPubScreens somethere, or dead loop , or kind. I almost sure that Designer slow because of the same, because of which EmbeddedDialogs slow. Slowdown feels very the same (one more pluse of idea that its all about one bug, not many different)
Speed is now the main issue, and I will try everything I can to fix this.
About the missing "middle button" tag in the prefs app, I forgot to copy the new version, I think the version in the SDK archive should be the right one.
EDIT:
Quote:
-- on running all QT apps ask for Cygnix: assign
Huh? I thought I fixed this... Just a small idea: If you type
About the missing "middle button" tag in the prefs app, I forgot to copy the new version, I think the version in the SDK archive should be the right one.
Right ! And should to say, that option rokz hard ! The way that its now spawn by RMB main menu in whole area, and by Middle button the context one : are fine enough and usable. The only moment, that maybe also add "native context menus" when "native menus" flag is set ? Just to make everything "in the style".
So, now that we can set the default style with a prefs application, the question is: How to make a OS4.x default style? And how can we motivate mason, imagodespora or some else to make such a theme?
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
.
