Re: How to prevent windows to be raised at the top of the stack when clicked?

["Olivier Guillion - Myriad" <olivier myriad-online com>]

Thank you very much, Sam,

It does make sense indeed.
I almost abandoned the idea of managing completely the stacking order at 
application-level, and tried to find a way to distribute my windows into 
several non-intersecting stacking groups.
By using the "gdk_window_set_type_hint()" function, I could identify 4 groups, 
from top to bottom of the z-order stack:

- Above any other window (including the windows from the application that 
currently has the focus) : GDK_WINDOW_TYPE_HINT_DOCK

- Below that, GDK_WINDOW_TYPE_HINT_UTILITY or GDK_WINDOW_TYPE_HINT_TOOLBAR or 
GDK_WINDOW_TYPE_HINT_MENU or GDK_WINDOW_TYPE_HINT_DIALOG

- Below that, GDK_WINDOW_TYPE_HINT_NORMAL or GDK_WINDOW_TYPE_HINT_DROPDOWN_MENU 
or GDK_WINDOW_TYPE_HINT_SPLASHSCREEN or GDK_WINDOW_TYPE_HINT_POPUP_MENU or 
GDK_WINDOW_TYPE_HINT_TOOLTIP or GDK_WINDOW_TYPE_HINT_NOTIFICATION or 
GDK_WINDOW_TYPE_HINT_COMBO or GDK_WINDOW_TYPE_HINT_DND

- And at the very bottom, below any other window, even the windows from other 
applications that don't have the focus : GDK_WINDOW_TYPE_HINT_DESKTOP

I presume that, internally, the WM manages these type hints by setting the 
values that are described in the link you provided: 
http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#STACKINGORDER

It's not completely satisfactory, because for instance, when tool palettes are 
clicked they will raise above the currently open dialog box. This drawback 
doesn't seem to be avoidable (e.g. I also noticed it in The Gimp), but it seems 
to be the best result I could expect from this OS. By comparison, this feature 
is quite straightforward under Windows or MacOS.

Thanks !
Olivier


Sam Spilsbury <smspillaz gmail com> wrote:

> Hi,
>
> On Thu, Feb 14, 2013 at 12:17 AM, Olivier Guillion - Myriad
> <olivier myriad-online com> wrote:
> > Hi,
> >
> > I'm struggling with this problem for several days now, and can't find any
> > solution.
> >
> > I'm writing an application for Ubuntu using GTK in C language.
> > This application manages various windows (floating palettes, documents,
> > toolbars, etc), with a complex stacking (Z-order) strategy.
> > I would want to manage the stacking myself, by calling gtk_window_restack
> > appropriately.
>
> Warning, here be dragons. Applications don't have full control over
> their stacking order or stacking policy, except if they are override
> redirect and the window manager does not touch them at all.
>
> > It works well, except for one thing : when a window is clicked, it seems to be
> > automatically sent to front (top of the stack) by the system before my program
> > receives any signal. For instance, if I put a breakpoint in the
> > "focus_in_event" or "button_press_event" signal callback, the window has
> > already been sent to top before the breakpoint is reached.
> >
> > Is there a way to prevent a clicked window from being automatically sent to
> > top of the stack ? Any help would be greatly appreciated.
>
> There isn't really.
>
> You can set _NET_WM_STATE_BELOW to make the window manager put it on
> the same layer as all of the "below" windows [1]. The window manager
> will still freely raise any window within this layer. Then you can use
> WM_TRANSIENT_FOR in order to force ordering amongst your windows. That
> ordering won't be exclusive though - it is entirely possible that
> other windows can go in-between.
>
> The reason why the window is automatically raised is because the
> window manager has a passive grab on the parent window if its not on
> the top of the stack. This grab activates and prevents your
> application from receiving the first mouse click until the window
> manager has done what its wants to do, namely, place the window at the
> top of the stack. This is part of the reason why people want client
> side decorations.
>
> I'd suggest reconsidering the design of your application. There are
> very good reasons why window managers needs to manage the stacking
> order, allowing applications to override that behaviour generally
> results in trouble.
>
> [1] http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#STACKINGORDER
>
> > Thank you,
> > Olivier
> > _______________________________________________
> > gtk-app-devel-list mailing list
> > gtk-app-devel-list gnome org
> > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
>
>
> -- 
> Sam Spilsbury