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 <smspil...@gmail.com> wrote: > Hi, > > On Thu, Feb 14, 2013 at 12:17 AM, Olivier Guillion - Myriad > <oliv...@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 > > _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list