Re: Window manager interaction

[Richard Frith-Macdonald]

On 17 Oct 2009, at 12:04, Philippe Roussel wrote:

> On Sat, Oct 17, 2009 at 07:02:12AM +0100, Richard Frith-Macdonald  
> wrote:
> > It sounds reasonable to allow interface style to control that sort of
> > thing, and the behavior you suggest makes sense for a windows app.
> > I'm not sure it addresses the original case though ... which was  
> > not for
> > an app running on windows and where, specifically, we know we don't  
> > want
> > to have the app close when  the last window closes.  So we probably  
> > still
> > need to retain defaults for more fine grained control over behavior
> > rather than just forcing a microsoft style behavior.
> > It's not a problem really to do both microsoft style behaviors and  
> > user
> > defaults for fine control.
>
> Just for the record, I like the vertical menus :o)
>
> > Anyway ... see what you think of the change to allow unhide by  
> > showing
> > the app icon when the app is hidden, and think about how it would  
> > be if,
> > instead of showing that, what we actually did was show a miniaturised
> > version displayed in whatever way the window manager normally   
> > handles
> > miniaturised windows (eg in a task bar).
>
> It works for me (under Metacity), thanks Richard ! I think this is a
> big step for better integration. I would prefer something to appear in
> the task bar instead (so demanding...) of the appicon but it's a  
> start.

I'm glad that the partial fix helps, but I'm afraid I'm going to have  
to withdraw the idea of using the standard miniaturise/deminiaturise  
behavior to integrate with window managers.

I made that proposal based on the assumption that window  
miniaturisation and deminiaturisation works, but when I actually tried  
to use it, I found it really doesn't in the current gnustep  
implementation :-(

In the first place, the method to inform the gui that a window had  
been deminiaturised was not being called, and there was actually no  
event defined for the backend to pass this information to the frontend.

I added the event event type so that the backend could tell the  
frontend about deminiaturisation, and then went to look at changing  
the backend to send it, and this is the point where, after hours of  
investigation I just had to give up ... it seems that the X-windows  
system simply doesn't provide any mechanism for you to know that a  
window has been deminiaturised.

If the backend doesn't know, it can't tell the frontend, and if the  
frontend doesn't know, it can't send the notification it's supposed to  
send ... which means we can't have code in the frontend waiting for  
the app icon window to be deminiaturised and trigger an unhide  
operation.  This is all very sad.

Now, I suppose it ought to be possible to figure out a way to reliably  
lock frontend and backend together so that the backend can infer a  
deminiaturisation from a particular sequence of events, but sorting  
out that sort of interaction is beyond me right now ... it seems that  
when a window is ordered in, it's pretty indistinguishable from a  
window being deminiaturised.


One option might be to scrap the backend miniaturisation/ 
deminiaturisation API entirely, and have the frontend strictly  
implement that  using the window/miniwindow counterpart pairing.  So  
to miniaturise a window, we order in the counterpart miniwindow  
(implicitly ordering the main window out), and to deminiaturise the  
window, we order it in (implicitly ordering the miniwindow out), and  
let the backend decide what it's going to do about the way it displays  
that on-screen.
In the case where we don't have real counterpart miniwindows because  
the window manager is actually just putting labels on a taskbar, i  
guess the backend could provide some sort of dummy placeholder.

Anyway .. that's just an idea ... don't know how much it would really  
help simplify things.