[Xlib] Saving state before an unmap

[Andrew Troschinetz]

Glynn Clements wrote:

> Andrew Troschinetz wrote:
>
>> 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.

Well, why don't we just agree that they can be difficult (very  
difficult) to reason about? The computer scientist in me takes some  
exception to "non-deterministic" being thrown about so lightly.

>> 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'll keep that in mind.

>> 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?

I see your point there. I guess I am trying to arm wrestle the WM just  
a bit with that feature. Still it's a requirement I can't avoid so  
I'll have to hack something together to solve it. I have something now  
that does what I want but it's very ugly. I thought maybe this problem  
had been encountered before and someone knew of a less ugly way to  
solve it.

> 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.

"Window-manager-lite" isn't exactly a technical term, sorry for the  
confusion it caused. I'm not writing a WM, but I am writing this  
menubar application which, to our users, will seem like it is the sole  
controller of all the windows they see. That's because in our system  
no other affordance will be given to move windows, minimize them,  
close them, etc... In that sense the menubar is "managing" the  
windows, but not in the sense that it manages them like how a WM  
manages windows.

> 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.

All good points. My problem is much harder than I had thought. But  
this is usually what happens when I get requirements handed down to me  
from a ivory tower committee without any actual programmers on it. Sigh.

>> 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.

Well at least I know we're on the same page now :)

>> 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.

Yes and now I understand better why gtk_window_set_decorated() only  
works on windows that haven't been mapped yet. And why the docs use  
wording such as "GTK+ will do its best to convince the window manager  
not to decorate the window."

So I must do my best to convince the WMs I'm deploying on to bend to  
my will. It sucks but that's what I've been tasked to do and I guess  
the hack I have in place now is ugly by nature, and that can't be  
helped.

Thanks for all the information, I feel like I'm much better equipped  
to deride that ivory tower committee whenever I get the chance to.  
Which will probably be never, but ... such is life.

--
Andrew Troschinetz
Applied Research Laboratories