Three different tab implementations

[Jörg Walter]

On Friday, 31. January 2003 12:12, Neil Stevens wrote:

> > On Friday 31 January 2003 01:14, Rob Kaper wrote:
> > > There are currently three different tab implementations in KDE:
> > > Konqueror, Konsole and Kopete each have their own framework for tabs,
> > > with different keybinding shortcuts and different behavior.
> > >
> > > Is anyone considering to merge all this into a single tabbing
> > > framework to be reused in applications? If people can't handle SDI,
> > > fine, but that's no reason for code duplication.
> >
> > I think it was already established some time ago that we should have
> > better support in kdelibs for consistency among MDI applications. Now is
> > an excellent time to work on that.
>
> OK.  Shall I remove the document interface standards page then (along with
> fixing the links)?  Doesn't make sense to have standardizing on SDI or MDI
> if KDE isn't going to have a standard anymore.
>
> http://developer.kde.org/documentation/standards/kde/style/basics/windows.h
>tml

Hi!

I think before thinking of fundamentally changing any guidelines, it should be 
established what the users (and thus, KDE) want. To do so, we need use cases. 
Why are people using tabs instead of SDI, when do users prefer SDI, and might 
there even be cases when they prefere classic MDI?

I can only talk of myself, but I am using each of the three modes in the 
appropriate situation.

I'll show the use cases I encountered using kate, kmail and kvirc as examples. 
I currently use two (different resolution) screens with Xinerama enabled, and 
a single screen on the laptop. My considerations apply to both situations.

First of all, I prefer tabbed MDI most. All three applications support this, 
though all three now use a listbox or tree widget as "tabs". The reason is 
simple: If i'm going to read mail, I want to do just that. If I rework some 
web site/program/perl modules/... I want to do that efficiently, with easy 
switching between the involved files. If I'm chatting, ... you get the idea.
The reason is simply that the global task bar doesn't give me the fast, easy 
and correct navigation a tab bar gives me: The tab bar is usually nearer at 
the mouse cursor, thus more easily reachable. It offers (context-wise) the 
best choices. And it doesn't require a mental switch to outside the current 
window.

Then there is the multi-screen issue, and this applies to single screens as 
well, for example when using multiple virtual desktops. I often double-click 
an email to put it beside the work I have to do - on a different screen 
and/or desktop. I wouldn't want the whole of kmail lying there. Likewise for 
kate/kwrite: viewing the source of a web page to see what's wrong, it opens 
kwrite, which is very appropriate since I can put it beside the web browser 
and the screenshot of the expected result. And the chat: kvirc allows you to 
detach MDI windows into top-level windows, so I can ignore the chat and leave 
it alone on a different desktop until I take a break, but can chat with that 
one person I really want to talk to beside my work. These are the classic 
pro-SDI scenarios.

But even old MDI isn't that bad. In kvirc, I usually "work" MDI-full-screen 
(i.e., tabbed). Yet sometimes it is useful to open 6 windows and let kvirc 
tile them inside the MDI workspace so I can see them all, _but still confine 
them to the total size I chose_ (they shouldn't occupy the whole screen!).
The same goes for konqueror and it's "split window" feature. The important 
factor here is that I can arrange things I want, and then move the whole 
thing around without destroying the internal arrangement, and that I can have 
it auto-arranged for me while restricting it to the amount of screen space I 
chose.

I wouldn't want to miss any of the three modes, and that many apps support two 
or three of them is a good indicator that others won't, either.
There was a suggestion that the WM should handle this through a generic 
protocol. In theory I consider this the best idea, and doable (even in the 
face of keybindings, tree widgets, different toolkits, ...), but it surely 
needs a lot of thoughts and cooperation from all sides to get that right. I 
don't particularly like the Flux example, it looks 'bolted-on'.
But in any case, it definitely is horrible to have 5 tabbing codes with either 
alt-left, shift-left, ctrl-shift-tab, ctrl-left and whatever keybindings 
might be there, each one looking and behaving slightly different.
IMHO, there could be _one_ "Real Tabs" tab mode, one "Listbox like in kate" 
mode and one "Tree" mode to be re-used by applications (not user-choosable).

As for the style guide, I suggest adding that MDI/tabbed MDI may make sense, 
depending on application context, but that no app should ever think of not 
supporting SDI as well (even if it is technically seen a different app, like  
the kate/kwrite combo).

And a very personal opinion: I think "Controlled SDI" (see the style guide) is 
rubbish. If you have 2000 documents, Listbox-style or Tree-style tabbed MDI 
is way better to handle this amount efficiently. Since you (hopefully) have 
the option to open a document in SDI mode manually, you don't lose 
flexibility.

-- 
CU
  Joerg

PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc
PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E  7779 CDDC 41A4 4C48 6F94