Re: Window manager interaction

[Richard Frith-Macdonald]

On 18 Oct 2009, at 05:31, Sheldon Gill wrote:

> Actually, I think it would simplify things a great deal if we  
> dropped the miniwindow entirely.
>
> I believe the fundamental problem here is one of design and the flaw  
> is trying to get -gui to handle miniwindows. For any compatibility  
> desktop we want to consider (GNOME, KDE, MS-WIN...) the answer is  
> conceptually straight-forward:
>   a window sets its state to whatever, including MAXIMIZED,  
> ICONIFIED/MINIMISED
>   the desktop environment does the display
>
> So what -gui should be doing is just that, setting the window state  
> appropriately and letting the backend translate that into the  
> desktop environment.
>
> The architecture is supposed to go like this:
>
> The application handles it's windows and draw in them/etc.  This is - 
> gui & -back.
>
> The window manager decorates the windows and provides the mechanisms  
> for users to interact with them. (Move them around, re-layer, pin,  
> show/hide, whatever)
>
> The application manager (pager) handles launching applications,  
> showing what is running and switching between them. This is the  
> taskbar / kicker / fiend / dock thing.  This is the thing which  
> would be displaying miniwindows for those desktop environments where  
> its appropriate.
>
> It seems to me that we're trying to get -gui/back to sometimes be a  
> window manager and sometimes be an application manager and getting  
> (understandably) very confused.

I happen to like minwindows (they were great in NeXTstep), though I  
agree that the world has standardised on a less functional mechanism  
and the advantage of the miniwindow (allowing user interaction with a  
minimised window) is, as a consequence, practically never used.  On  
the other hand, maintaining OpenStep backward compatibility is not the  
issue here.

The problem I was talking about really has nothing to do with  
miniwindows (and doesn't involve trying to be a window manager) and my  
mention of miniwindows was only as a possible way to simplify the  
frontend-backend api a little for clarity, by handling minimise  
strictly using the ordering API with miniwindows (you could equally  
use a special API for it and not use the ordering API for miniwindows  
at all, but the point was to avoid having overlap between the ordering  
and minimisation APIs).

The actual problem is that X doesn't differentiate between a window  
being mapped and a window being de-iconified,  so you can't know when  
a window is de-iconified in order to send the notification mandated by  
the OSX NSWindow API.  In fact, this problem does not occur with  
miniwindows (since when X tells us a miniwindow has been mapped, we  
know that the normal window has been miniaturised, and when X tells us  
it is unmapped, we know the normal window has been deminiaturized).   
The problem ONLY occurs when we are using the standard X mechanism/ 
architecture you describe.

Actually the lack of discrimination in what X tells us is only part of  
the problem, I guess the more intractable part is that the event queue  
prevents us from inferring  what's needed:

Consider the sequence of events ...
1. start hiding app
2. order in the window
3. minimise/iconfiy it
4. wait for notification that it has been unminimised
5. unhide application

at (2) we tell X to map the window
at (3) we tell X to iconify it (we have to do (2) first because at  
least some window managers don' allow you to iconify an unmapped window)
at (4) X tells us that the window has become visible, which would  
ideally mean that it was de-iconified, but is actually the event  
resulting from the window being mapped at (2).

This means that the hide operation usually results in an immediate  
unhide simply because an old event looks like it is a deminiaturise.

I've experimented with various ideas to solve this, but without  
success so far ... any ideas from X coders would be good.