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