[Xlib] Saving state before an unmap

[Lubos Lunak]

On Wednesday 11 of February 2009, Andrew Troschinetz wrote:
> Hi all,
>
> 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. Take the _NET_WM_STATE property
> for example, it gets blown away if you unmap the window. This results
> in things like a window being kept-below before I fiddle with it, but
> then after I remap it, the window will no longer be kept-below anymore.
...
> There has to be a better way, right?

 Yes, there is: Don't fiddle with it. There are requests for asking to change 
some properties while a window is mapped. From the window manager's point of 
view, unmapping a window and destroying a window is about the same.

> Alternatively, if there is a way to remove the close/minimize/maximize
> buttons or window-decorations from a window w/o unmapping it (or w/o
> losing the window's current _NET_WM_STATE property) that'd be awesome.

 No, there is not. Altering the window decorations/buttons is something under 
the control of a window manager and many of them do that based on what makes 
sense and not on what some application thinks would look cool.

> 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. It's a little complicated, but probably not as complicated as
> I'm making it sound. 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.)
>
> Any ideas?

 I think you should try to find somewhere a good description of what a window 
manager is, and specifically why it has 'manager' in its name - it is the 
window manager that is eventually in control of the windows and not the other 
way around. The more complicated things you try the more likely is that the 
window manager will have a different idea about it, so I suggest you instead 
consider to try to add your wanted features to your favorite window manager.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http://www.suse.cz