[Xlib] Saving state before an unmap

[Andrew Troschinetz]

On Feb 12, 2009, at 3:13 AM, Lubos Lunak wrote:

> On Wednesday 11 of February 2009, Andrew Troschinetz wrote:
>> 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.

You're making the assumption that I can choose not to fiddle with it.

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

Good to know. If I must unmap the window then that is what I must do.

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

Sigh. It's not productive for anyone here to be condescending. I'm not  
developing for a hobby and (sadly) my company doesn't pay me to  
develop OSS. The versions of the software we run are decided by  
committee (a committee that's not even part of our organization) and  
even if the features I want are in some version of some WM out there,  
it does me no good because I'm locked into specific versions of  
specific software for years at a time.

I'm developing a generic solution for multiple embedded systems. One  
of these systems will be running Motif Window Manager, and the other  
will be running Gnome. For now (and for the foreseeable future, as in  
at least 10 years down the road) it's enough if the software I write  
works on both of those managers. So you see, even if I hacked away at  
the WMs (both MWM and Gnome) to get the features I need, I wouldn't be  
able to deploy those solutions because the WM software is frozen in  
the baseline I'm targeting and on the target machines our software  
will deploy to and there's no way I could get approval to deploy my  
hacked versions of MWM or Gnome because that would affect many  
multiple different organizations.

In the final system, you won't have a panel or anything other than the  
application windows and an internally developed "menubar." This  
menubar will have to accept user input and control all the various  
windows of the entire embedded system.

Each window in this system is its own application. It wouldn't be a  
stretch to assume that each of those applications are developed by not  
only different people, but different organizations as well. But they  
all have to work together without clashing.

So I needed a way to say, for example, "Raise the Foo Dialog window  
now" that would work on both MWM and Gnome. The solution I came up  
with was using low level Xlib calls. Essentially there's a config file  
with a list of WM_NAMEs of all the windows on the system. An  
application I wrote parses that file and begins a typical XEvent main  
loop. That loop listens for commands from the user from the menubar.  
Those commands can be things such as:

1. Move a window.
2. Resize a window.
3. Iconify a window.
4. Present a window.
5. Remove (or add) the border (window decorations) from a window.
6. Remove (or add) any of the buttons from a window.
7. Set the transient of a window to any other window.
8. Make (or unmake) a window fullscreen.
9. Make (or unmake) a window keep-below or keep-above.

The only way a user of this system will have to raise/lower/move a  
window will be through interaction with the menubar. Many applications  
on this system run in fullscreen mode. The system is either in an all- 
on or all-off state, meaning no application ever quits. That's why I  
have to remove the close button from windows before the user can  
interact with them. Because if I didn't, and a user of the system hit  
that close button, the entire system would be out of spec and  
considered a failure (which would directly impact our funding, at the  
very least).

Hopefully that's a more clear explanation of my situation. I apologize  
if I was unclear before.


So I need an easy way to remove or add window-decorations (and I guess  
that means un-mapping and re-mapping the window) without losing any  
other window properties in the process. I guess that means saving all  
those properties and re-setting them after I re-map the window. That  
really kinds sucks but if there's no other way than that's what I'm  
going to have to do.

I suppose I need to save not only the _NET_WM_STATE but also all other  
_NET* properties I care about as well. But it seems like only the  
_NET_WM_STATE is affected by un-mapping/re-mapping in my testing...  
I'm not sure just how far I have to go to get this done.

--
Andrew Troschinetz
Applied Research Laboratories