Re: return of the MDI

On Fri, 14 Jan 2000, Antonio Campos wrote:

> Having window-in-window MDI could let you:
> * Iconify all MDI children when the parent window is iconifed. (Useful).

As has already been pointed out, this can already be done.  Sawmill
handles this well.

> * Manage MDI children inside the parent without boring the rest of
> toplevel windows in the desktop.

Discussion on the list lead me to believe that MDI preference was a
religious thing, and that trying to argue which was better was like trying
to tell people which was better out of vim and emacs.

Personally I don't think that hiding the MDI children from the toplevel
window is helpful - for a start it immediately breaks the standard
keyboard navigation of Alt+Tab.  That said, I do like notebook style MDI,
so I'm being inconsistent.. ;-)

> * Is someway clearer in word processors, image editors, in general...
> But well, window-in-window MDI won't let you dettach a MDI child from
> the parent (which could be useful sometimes).

Possibly.  There are a couple of hints that are going into the new WM spec
which will enable more powerful multiple window MDI.  With multiple window
MDI, you don't usually have a "parent", you tend to have a toolbar
window(s).  The new spec would allow a window manager to do things like
making the toolbar window(s) visible on all desktops where a child window
is present, and/or only visible when a child window has the focus.

> I came to reading in the GNOME Developers Interview:
> "We already have plans for a second spec, to include advanced features
> that would delay the release of the first spec too much. One possibility
> for this is window-in-window MDI (like Microsoft Word). Whilst this type
> of MDI is somewhat unpopular with many people, I think that supporting
> it would be a very good thing from the point of view of helping people
> porting stuff to X, and those developing cross platform apps.
>    [WM Spec Coordinator (] "
> My petition here is that simple MDI should be transfered to the
> GTK level (or even the GDK level is possible) and a more complex (is
> needed) GNOME MDI API could be built over the MDI GTK. (Why?. Simply
> because one sometimes would like to make a simple GTK program with MDI
> support without digging inside GNOME or requiring that the user has
> GNOME installed).

OK, first up the WM spec is not Gnome specific.  It is expected that most
window managers and (at least) the GTK and QT toolkits will adopt the
relevant parts of it.  The reason that window in window would have to be
in the WM spec, is because it requires some assistance from the window

The problem is in decorating and managing the child windows.  Ideally you
want them to appear in the same style/theme as the top-level windows.  
This means that you want the window manager to decorate them, but they
aren't top level windows.  There is no neat & clean way to work around
this under X.  Any solution that allows the WM to manage child windows,
whilst keeping them within the confines of the parent window will require
quite some help on the part of the WM, and several WM authors have stated
that they have no intention of implementing it, even if it were part of
the spec.  OTOH Matthias Ettrich from KDE/KWM is planning to implement it
at some point.  When he (or someone else) does, that implementation of it
will probably go in to the spec, so that those WMs that do wish to
implement it can do so in a standard fashion.  Matthias also notes that
because not all WMs will support WinW MDI, there will also be a toolkit
implementation of WinW so that the client windows are managed by the
app - they will not share the same look'n'feel as top level windows (see
Star Office for an example of how yuck this is).

Irrespective of people's religious beliefs about the UI advantages of WinW
MDI, from an implementation-in-X point of view it is Yuck.  



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