On Oct 27, 2008, at 3:44 PM, Trenton Schulz wrote: > > On Oct 24, 2008, at 8:44 AM, Peter Johnson wrote: > >> The always-on-top feature (Qt::WindowStaysOnTopHint ) seems to be a >> little bit off with Qt 4.5 tp1 on Mac and Linux. >> >> On the Mac, if I turn the Qt::WindowStaysOnTopHint on for my >> QMainWindow, then the QMainWindow is *really* on top. Even menus >> from >> the menu bar go behind the window. I would expect menus and modal >> dialogs and utility windows to still come up above the "always on >> top" >> main window. This is especially problematic if the application >> displays an error message, or if it accesses the "Keychain" which may >> put up a system dialog behind the "always on top" window. > > We intentionally decided that StaysOnTop really was stays on top on > the mac. In general, you can use things like Qt::Tool which will put > things on the correct window level on the mac.
For a window with menus, it doesn't seem like it would ever make sense for the menus to come up behind the window. > >> I think this can be easily solved by just using a lower window level >> (maybe NSFloatingWindowLevel / kCGFloatingWindowLevel) associated >> with Qt::WindowStaysOnTopHint. > > It's something to keep in mind, but I believe we put it up that high > because we had people complaining that the window really wasn't on > top. For a "document window", what I want is "always on top" to mean always on top of other document windows, but other important windows such as dialogs and alerts (even from other apps!) should still come on top. Dialogs and alerts are there because they require user interaction-- but that can't be done if they are obscured. The biggest problem I have with the current implementation is that system dialog windows, which may block my event loop, can come up behind the main window. The prime example is the Keychain "do you want to allow the application to access the keychain" dialog. My app accesses the Keychain at launch and this may put up a blocking dialog that the user can't see and the app isn't even aware of. But I can see how other situations might call for an "on-top" window being that high--perhaps if you intentionally want to take over the entire desktop. The ideal solution would be to let the developer decide what level it means. I don't suppose you'll be adding a "setMacWindowLevel()" API, but perhaps I can just get the Carbon WindowRef and set the layer myself instead of using Qt::WindowStaysOnTopHint? > > >> >> >> Linux has a similar issue, at least on Ubuntu 8.04, where dialogs >> come >> up behind the Qt::WindowStaysOnTopHint window. > > Are the dialogs associated with the window below it? E.g. a dialog > with always on top window as its parent working? If not, that > probably needs to be looked at. No, the dialogs are not associated with the window. Some dialogs aren't logically associated with the main window, and as I've noted, some aren't even coming directly from the app, but from OS X system frameworks. _______________________________________________ Qt4-preview-feedback mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt4-preview-feedback
