On Mon, Aug 10, 2015 at 1:04 PM, Jasper St. Pierre <jstpierre@xxxxxxxxxxx> 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. _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
