Three different tab implementations

[Lubos Lunak]

On Friday 31 of January 2003 12:33, Neil Stevens wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Friday January 31, 2003 03:15, Waldo Bastian wrote:
> > On Friday 31 January 2003 13:56, Jan Van Dijk wrote:
> > > If tabs are considered Bad Practice, a note in the style guide may be
> > > appropriate.
> >
> > The style guide mostly takes offense with MDI implementation such as Qt
> > Designer where the application unnecassery restricts the placement of
> > windows and imposes his own idea of a desktop on the user. Star Office
> > is another example of such restricting interface.

 Agreed. This kind of MDI is simply braindead, especially if it can't be 
turned off.

> >
> > Tabs are a whole different class of MDI, they also restrict the user in
> > the sense that only one document at the time is visible, but in this
> > case that can be considered a feature assuming that the user has
> > deliberately choosen to use this in order to better manage a substantial
> > set of similar documents.
>
> Tabs may be a whole different class of MDI, but every word you said in the
> first paragraph applies to them equally well.
>
> And unfortuantely some MDI apps in KDE do not give the user a choice
> choice.  KDevelop and Quanta come to mind.  There it is MDI or nothing.
>
> > One could also argue that the desire to use the above mentioned forms of
> > MDI comes from the lack of grouping facilities in the current generation
> > window managers. But I don't think that's a very strong argument unless
> > you can come up with a window manager that indeed manages to take away
> > that desire.
>
> But it's not a question of just accepting MDI or not, is it?  There's more
> being asked for here, and there are more options available:
>
> a. Let developers do MDI on their own (ignoring it and wishing it would go
> away)

 This is really a bad option.

> b. Develop a standard MDI system and port all MDI apps to it (what Rob
> seems to be asking for here)
> c. Develop a window manager spec for tabbing systems, and implement it in
> KWin (likely involving, and benefiting from, GNOME and other window
> manager developer input).
>
> Right now we've had a).  To me, if development is to be expended, c) is
> better than b) because c) will:
>
> 1. Give MDI support to all apps (including SDI apps both KDE and not), for
> fans of MDI
> 2. Give developers more reason to develop SDI apps, which will lead to SDI
> available for those who prefer that interface style
> 3. Give KWin task-oriented features like it never had before, transcending
> the app-centered MDI/SDI options.

4.  Make apps more resource hungry. I could be now running one Konsole, one 
Konqueror and one KSIRC. Having MDI as WM-only would change that to eight 
Konsoles, two Konquerors and three KSIRCs (besides KSIRCs, I actually run it 
so now, but that's not the point, I don't have to). You could argue you could 
have one app simply create more windows, but those wouldn't be really 
independent, even if they looked so (just try an error dialog in Konqy having 
more windows), with tabs it would be more obvious they belong together.

5. This is not really an argument against, I'm just curious. How exactly would 
you want to represent several windows that form some kind of "project" 
together? Say KDevelop with list of files on the left, output views at the 
bottom and other windows for the C++ files? Or KSIRC? Tabs seems to fit here 
nicely, especially if they can be undocked and become real toplevel windows. 
If you convince me here, the opinion of KWin maintainer could matter in this 
discussion :).

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/