[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Window manager interaction

From: Richard Frith-Macdonald
Subject: Re: Window manager interaction
Date: Sat, 17 Oct 2009 19:45:37 +0100

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]