Re: How to prevent windows to be raised at the top of the stack when clicked?
Hi, Lucas, Vous avez écrit (you wrote:) It's not completely satisfactory, because for instance, when tool palettes are clicked they will raise above the currently open dialog box. Not exactly. Depending on the WM settings, a click may well not raise the window. The fact is: *you* cannot prevent some windows to be raised above some others if the user wants to, but the user may also decide that a click do not raise the window. You are right. I would have said when tool palettes are clicked they *might* raise above the currently open dialog box, depending on the WM, its version, and a bunch of user's settings. In other words, even if I find a way to make it work as I expect, probably other WMs or some user settings could ruin my efforts. Uncertainty is the enemy of consistency... By comparison, this feature is quite straightforward under Windows or MacOS. Probably right. Those OSes are well known for their I know what you need better than you behaviour ;) Well, in this case it's exactly the other way round. :) Here, the WM is doing things automatically. It decides that any clicked window has to be raised on top (or not), because it thinks that it knows better than me (the programmer) how to manage the application window stacking... Regards, Olivier Olivier Guillion Myriad 26 rue Michel de Montaigne 31200 Toulouse FRANCE WebSite--- http://www.myriad-online.com Download here the latest version of our shareware programs, view the online tutorials or get info about Myriad and its activities. - ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to prevent windows to be raised at the top of the stack when clicked?
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
Re: How to prevent windows to be raised at the top of the stack when clicked?
Hi, I made some more tests about the solutions that seem to be useable. It appears that they are not. Reminder: the problem is to let the application manage window stacking (z- order), instead of letting the Window manager do most of the job by itself. - The gtk_windows_set_transient_for() function works but : . It's not possible to change anything in the window stacking order without rebuilding the whole list from scratch . When the list reaches 16 windows and more, this operation takes exponentially more and more time. With 20 windows, it takes several seconds. With 25, the whole system hangs. - The gtk_window_restack() function works but : . When a window is clicked, it seems that the WM automatically send it to the frontmost position in the stack, without letting the application avoid that. . I couldn't find any way to prevent that behaviour from the WM by altering the .XDefault/.XResources file Could it be possible to bypass GTK and to access the X structures and events directly? If yes, is it a way to prevent it to bring automatically the clicked window to front ? Regards, Olivier ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to prevent windows to be raised at the top of the stack when clicked?
Michael Cronenworth m...@cchtml.com wrote: Is there a way to prevent a clicked window from being automatically sent to top of the stack ? Any help would be greatly appreciated. You can use gtk_window_set_transient_for() to force stack ordering. Thanks, Michael, I already tried it, and it didn't work as expected. To manage the stacking order properly, each window has to be set transient for the window below it in the stack. But changing the order in this transient list doesn't work as expected : sometimes windows remain at their previous Z- order after the call. It seems that gtk_window_set_transient_for() is merely designed to manage dialog boxes that open over a document window, and not to apply changes to existing windows stack ordering. I'm still trying to go further with this function though. So far, the only solution I could find with this function is, when something changes in the stack order, to delete the transient info of each and every window, then rebuild it entirely. It seems to work, but it's not straightforward. I'll tell here the results of my experiments. Regards, Olivier Olivier Guillion Myriad 26 rue Michel de Montaigne 31200 Toulouse FRANCE WebSite--- http://www.myriad-online.com Download here the latest version of our shareware programs, view the online tutorials or get info about Myriad and its activities. - ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to prevent windows to be raised at the top of the stack when clicked?
Thank you, Kurt ! I'm a complete newbie in Linux programming, and I didn't realize that the window manager could be configured on an application-basis. It worth definitely a look. Thanks again, Kurt M. Bruhnke wrote : Have you tried looking at the settings for your window manager? I know with mwm (yes, I still use it) you can change the button bindings so that, for instance, a mouse button down in a window can call f.nop instead of the usual f.raise. Depending on how standardized your window manager wants your applications to behave, you might be able to fix your problem by reconfiguring your window manager. You may even be able to do this on a window class or window name basis which would be done in .Xdefaults. Olivier Guillion Myriad 26 rue Michel de Montaigne 31200 Toulouse FRANCE WebSite--- http://www.myriad-online.com Download here the latest version of our shareware programs, view the online tutorials or get info about Myriad and its activities. - ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
How to prevent windows to be raised at the top of the stack when clicked?
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. 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. 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
