Andrew Troschinetz wrote: > >> I realize that all I can do is set hints and make requests. However > >> those actions have concrete results in terms of WM response. The only > >> thing that matters to me is figuring out exactly how to prod the WM > >> in such a way as to get the responses I need. > > > > You can't. You set hints and make requests; how (and even if) the WM > > responds is up to the WM. The relationship between the hints and the > > end result is intentionally vague. > > Window Managers are not non-deterministic, though they may be complex > and vague.
They may as well be non-determistic, as you don't have access to all of the information which controls their behaviour. > When a WM purports to support the EWMH specification, I > would except near compliance with that specification and *nothing > more*. Bear in mind that "compliance" simply means that they interpret the requests correctly, not that they necessarily honour them. > I am operating within the confines of those specifications and > their implementations. It frightens me somewhat that you find that > unsettling. What some of us are taking issue with is the remarks from your original post, some of which suggest that you have quite specific expectations about the WM's behaviour, e.g.: Basically I want to unmap a window, fiddle with it a bit (like removing the border, removing the maximize button, etc...) and then remap it. The problem I'm running into is that unmapping the window results in unintended side-effects. If unmapping the window has "unintended" side effects, so be it. You make a request (unmap the window), the WM does as it sees fit. What's the problem? Also: Essentially, I'm writing a "window-manager-lite on top of a real window manager" so that I can manipulate all the windows of all the disparate applications of the software suite I'm developing in various ways. Either you're writing a WM, or you're not. Utilities such as pagers are typically tied to a specific WM, even to the point of being part of the same source package as the WM. Probably because the "global" conventions don't provide the mechanisms necessary to write a pager which works reliably with any WM. And: Essentially the use case is that the user may at any point command the window of another application to remove (or un- remove) its border/close-button/etc, and I need to respect as much of the current window state of the target window as possible (ie: _NET_WM_STATE and possibly other Extended Window Manager Hints properties that I haven't even thought of yet.) The first part is simple enough: server-side resources such as windows aren't really "owned" by clients, beyond the fact that they will normally be destroyed when the client terminates. Any action you can perform on a window which you created can be performed on a window which another client created. The hard part is that the creator may have its own ideas about how it wants the window managed, and not all of that information will be visible to you. Some of it may only exist in the form of the program logic which determines how the client responds to events relating to the window. The only information which the client is likely to make visible is that which the standards require it to make visible in order to achieve its goals. If the window gets minimised, maybe the client will do something in response, maybe it won't; who knows? The fact that the _NET_WM_STATE property is cleared when the window is withdrawn isn't a problem. If the client subsequently decides to re-map the window, it will set this property accordingly before it does so. Okay, so your program doesn't know how the client intends to set it (if the client even handles this situation), but the standard wasn't written with your program in mind. For the case where it's the WM (in the broadest sense, which would include WM "components" such as pagers) which is messing with the window, there isn't a problem either. The WM knows exactly which properties it understands and what it does with them, so it can preserve or modify those as necessary. Your program doesn't know about any of that, but ... such is life. > What exactly do you think the mechanism is for raising a > window when the user clicks on its proxy on a panel like gnome-panel? Without looking, I would think that the mechanism would be to call either XMapWindow() or XMapRaised(). What the WM does about that is anyone's guess. > Look guys, GNOME *has* the functions gtk_window_set_decorated() and > gdk_window_hide(). I am not trying to do something out of the ordinary > here. I'll thank you kindly to stop imposing your assumptions on me. There's a big difference between using the standard APIs and what you outlined in your original post. -- Glynn Clements <[email protected]> _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
