On Wednesday December 09 2015 13:51:47 Martin Graesslin wrote:
> > KWindowSystem::setMainWindow() is a different matter. Firstly, it does NOT
> > use the plugin architecture currently, but simply assumes that
> > QWindow::fromWinId() will always work (and never crash).
>
> oh that explains a lot... Like why couldn't I find it in my Wayland backend,
> why do random applications crash on Wayland...
You actually missed this? :)
> nah, won't help. Well would help for OSX, but not for Linux/Wayland. I think
> we need to move it to plugin architecture, too.
I agree. When I said "for the time being" that was also because I have been
developing my MacPorts build/packaging scripts at the same time as installing
(bootstrapping) KF5, and even the current KWindowSystem git/head refuses to
build against 5.16.0 (and I'd just as well have only a single set of build
directories). Oh well...
Is Wayland detection purely a runtime thing?
> > Beyond that I suppose that setMainWindow() is *not* the place to push the
> > new window to the foreground so that it doesn't get overlooked - or is it?
> > In other words, what exactly is the role of KWindowSystem's main window?
>
> It's an X11 thing (like most KWindowSystem methods) for parent-child
> relationship. It's not about raising windows, etc. That's up to the windowing
> system.
That confirms my impression about setMainWindow(). As to the "up to the
windowing system" bit, that's a lot less simple.
From what I understand, the purpose of using a WId from another application is
to ensure that the newly created window/dialog displays alongside the windows
of that application (above them if the window manager is set to stack new
windows that way). On OS X, windows are always opened in front of the other
windows of the same application (unless the application instructs differently).
Assuming that that owning application is frontmost (the one being used
interactively) when the dialog is created, that should be a sufficient way to
ensure that the dialog is seen by the user, without forcing it to the front or
even setting a WM hint.
In practice it doesn't always work that way; even on X11 things like wallet
password requests tend to "pop down" somewhere behind a random amount of other
windows. That happens often enough that I patched the akonadi mail transport
agent so that it handles wallet unlock timeouts more intelligently.
On OS X it would be systematic, which was among the reasons I made a Keychain
backend for KWallet; at least the native API puts password unlock requests up
right in your face. Annoying at times, but appropriately so IMHO.
This is why I asked if there are classes where it would make sense to force a
window to the foreground if it cannot be opened alongside (= just above) the
windows of the application that's responsible for that new window's creation.
KMessageBox seems like a justifiable candidate to me.
Note: if an application posts an alert on OS X it will depend on certain things
if that alert is posted in front of everything else (alert type among others).
I'm not sure I really know the rules but it's a fact that every so often you'll
happen upon an alert that got posted somewhere behind other things (or on a
different "Space", virtual desktop) ... or you are alerted by another signal
that draws your attention to some background app that requires it. Typically
that will be a bouncing Dock icon ... and evidently that's not possible in a
background app ("agent") that doesn't have Dock presence.
R.
_______________________________________________
Kde-frameworks-devel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
