[KDE/Mac] [OS X/Wayland] using WIds created by a different process to create KMessageBox'es and other widgets/windows

[René J.V. Bertin]

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.