Re: Desktop as transient window

[Paul Davis <paul linuxaudiosystems com>]

On Mon, Aug 10, 2015 at 1:04 PM, Jasper St. Pierre
<jstpierre mecheye net> wrote:
> The important thing is that we can tie a dialog back to context for
> the user -- we really want it on DEs like GNOME, and I've heard that
> KDE wants to get rid of transient-less dialogs as well, since they can
> just randomly show up to the user. When it's attached to a transient,
> then we raise the application along with it.

right, but this should be done via app-centric techniques, not
window-centric techniques. that is, the dialog should be known to
belong to an app, not to another window.

> Out of curiosity, since I'm not aware of OS X, what's the issue with
> using transient-parents there?

OS X has a much richer window layering model than X (and I think more
so than Windows also), with several different layering groups,
allowing windows to belong to a layer group and also to be ordered
within that group. It also has the concept of per-application window
layering. This is not done by explicit ordering by assigning a window
type to a window. The right kind of window will ALWAYS float above
other windows of that application that are in "lower layer classes".
In addition, the display manager will auto-hide various window classes
when the application loses focus.

Attempting to set transient parent on OS X leads to competing
mechanisms: explicitly layering via [NSWindow addChildWindow:WINDOW
ordered:ORDERING] and window type/class. There's basically never any
need for transient parent on OS X, and we wouldn't need it on X either
if X had this app-centric layering model.