[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: Sun, 18 Oct 2009 10:21:30 +0100

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.

reply via email to

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