Re: Design of MDI aplication

[Gus Koppel <gtk spamkiller bytechase cx>]

Petr Hracek wrote:

> I would like to ask you how I can design MDI aplication. Of course if 
> it's possible.
> where I can find some sources. In Gtk-demo I did not find anything.

Two answers:

1. there are currently two common ways for designing MDI (Multiple
Document Interface) in GTK+:

1.1. by putting each "document" into its own toplevel window

1.2. by having one main window with a GtkNotebook (tabs either visible
or invisible). Each "document" would then become a page inside that
notebook.

A few well designed applications offer the user the choice to change
between these two handling methods any time, at runtime, sometimes even
on a per window (per document) basis.

2. look at the following URLs for some more controversial information:
http://mail.gnome.org/archives/gtk-app-devel-list/2003-December/msg00141.html
http://mail.gnome.org/archives/gtk-app-devel-list/2003-November/msg00113.html

Essence: WiW (Windows in Windows), the 3rd way, as known from MS-Windows
or QT, are not supported by GTK+. Some people say fortunately, others
(including me) say unfortunately. My opinion on this is that just
because a few people (mainly developers) really dislike this feature
they shouldn't keep telling other users they have to dislike it as well,
even if they are no lusers and still feel comfortable with it.


Sidenote: I've written an own small GTK+ MDI management module which
allows to dynamically change any custom dialog between toplevel window
and notebook page appearance, controlled via arbitrary togglebuttons or
checkmenuitems. As it's not documented and not fully independent from
our application yet (which isn't open source) it isn't published yet. If
there shows up interest I could spend some hours to catch up on it.
However, likely something similar has been created by someone else
already?

I haven't had the time to do it yet but I still fancy writing an own
generic WiW implementation for GTK+, including floating, draggable and
resizable "windows" in "windows". Of course those internal windows would
have completely different look than the WM-managed top level windows, as
there is no generic way to determine dectorations and features of a WM.
However, at least to me the nice QT implementation of this proves that
it is something I (and likely others as well) couldn't care less about.

Motto: if you don't like such an extra offer of features then don't use
it but please don't tell other people they must not like it either.