[Xlib] Saving state before an unmap

[Andrew Troschinetz]

On Feb 16, 2009, at 4:02 PM, Glynn Clements wrote:

> Andrew Troschinetz wrote:
>
>>>>> 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.
>>>
>>> If that's what you call saying that things are the way things are.
>>> The window manager is eventually the one in control of all the
>>> windows, hence the name, and applications just give hints and
>>> requests. It is up to the WM to decide what to do with those and
>>> whether at all. I'm sorry that somebody told you to dig a garden
>>> with a pole, if the window managers you will use will be lenient
>>> enough and you will not want too complex things it may work with
>>> enough hacks, but it still doesn't change anything about the fact
>>> that you're trying to dig a garden with a pole. But if you want to
>>> find out on your own, fair enough.
>>
>> I don't believe the point you're making in any way addresses my
>> expressed goals. I would point out that 99% of the library I've
>> written to solve the issues I'm facing is exactly the functionality  
>> of
>> GNOME libwnck. From the description of the project libwnck is meant  
>> to
>> be "used to implement pagers, tasklists, and other such things."  
>> Which
>> is essentially what I'm trying to do. You wouldn't call being able to
>> raise a window by clicking on its icon in a pager digging a garden
>> with a pole, would you?
>
> That depends upon whether you're letting the WM do this or trying to
> do it yourself.

I'm using the ICCCM, EWMH, and MOTIF Hints protocols. These are  
standardized protocols supported by the Window Managers I'm targeting.  
I use direct Xlib calls in the same manner as they are used in the  
libwnck source. I'm doing it the only rational way there is to do it.  
I can't even begin to imagine what you could mean by "do it yourself."

>> Well instead of a pager I have a menubar, it's not that different.
>>
>> However libwnck is for GNOME, I am attempting to do something lower-
>> lever that will work (whenever possible or fail silently) on GNOME  
>> and
>> Motif (at the least -- however I would like to note that I have done
>> some cursory testing on KDE as well and it seems to work fine there
>> too).
>>
>> 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. When a WM purports to support the EWMH specification, I  
would except near compliance with that specification and *nothing  
more*. I am operating within the confines of those specifications and  
their implementations. It frightens me somewhat that you find that  
unsettling. 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?

>> I'm sorry if it horrifies you that I'm making my WM work for me,
>> rather than against me.
>
> It's not *your* WM, it's the user's. The desktop is a shared resource;
> it doesn't belong solely, or even primarily, to your application. Your
> application makes requests which the WM may or may not honour,
> depending upon competing requests from other clients, user
> configuration, and a zillion other factors.

I understand perfectly the request-oriented nature of the WM. As I  
have already pointed out multiple times, I am operating within that  
set paradigm. I'm sure you know, panels and pagers actually do exist  
and generally work quite well, in complete spite of the point you have  
made. They get their job done just as desktop users expect them to. I  
as well must get my job done if I'd like to keep it ;)

> The best that you can do is to learn how to speak the WM's language,
> so that you can ensure that your requests are heard and understood.
> You cannot ensure that your requests are honoured; this is deliberate.
>
> The only way to obtain complete control is to write a WM. You cannot
> realistically expect to force another WM to bend to your will.

I have already done as you say; learned to "speak the WM's language."  
However I'm sure you know it's a very complex and demanding language  
at times and sometimes I need a little help from my peers in trying to  
formulate words and phrases in it.


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.

--
Andrew Troschinetz
Applied Research Laboratories