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.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev