On Oct 28, 2008, at 7:20 AM, Peter Johnson wrote: > 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.
That seems like a bug and regression. Do you have an example? > > >> >>> 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? We don't plan on adding that API at a point in the near future. You can grab the Carbon WindowRef and Cocoa NSWindow pointer and set the level yourself of course. In this case, it's probably the best option for you. We could maybe add an application attribute or something that says how high you want the top to be. >>> >>> 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. OK. Well... that's somewhat expected, given how we defined "always on top." -- Trenton _______________________________________________ Qt4-preview-feedback mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt4-preview-feedback
