[Xlib] Saving state before an unmap

[Pat Kane]

Andrew,

Do either of these project help?

      <http://standards.freedesktop.org/xembed-spec/xembed-spec-0.5.html>
      XEmbed is a protocol that uses basic X mechanisms such as client messages
      and reparenting windows to provide embedding of a control from
one application
      into another application.

      <https://launchpad.net/libwnck>
      libwnck (pronounced "libwink") is used to implement pagers,
tasklists, and other
      such things. It allows applications to monitor information about
open windows,
      workspaces, their names/icons, and so forth.

On 2/13/09, Andrew Troschinetz <ast at arlut.utexas.edu> wrote:
> 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
>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>