[Xlib] Saving state before an unmap

Pat Kane pekane52 at gmail.com
Fri Feb 13 11:31:01 PST 2009


Do either of these project help?

      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.

      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

More information about the xorg mailing list