[Xlib] Saving state before an unmap

[Glynn Clements]

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 <glynn at gclements.plus.com>