Re: Desktop as transient window

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]