Three different tab implementations

[Martijn Klingens]

On Friday 31 January 2003 18:51, Christian Loose wrote:
> Other advantages (additionally to the ones stated by Neil):
>
> - Alt+TAB for switching between windows no matter if the app is in SDI or
> MDI mode.

This one alone is IMO invaluable to have.

Whatever route we take, the fact that currently alt-tab doesn't work is a real 
pain.

Also, in Konsole, which is the only place where I use tabs myself, the SDI 
code is really inadequate. I cannot drag a tab outside the window to make it 
a standalone view, I have to select detach from the menu, which is less 
intuitive. And the new window that I get is not a full Konsole window that 
allows adding other tabs but is only the representation of a single tab.

Ideally one would even be able to move tabs to a konsole window belonging to 
another process. Technically there's the process distinction but as a user I 
couldn't care less, as I'm working with windows of the same application 
(binary, not instance). If MDI handling gets window manager support all this 
comes almost for free, but now it will be hard to get right.

The best MDI to me seems to have the handling in the WM, but use some simple 
notification like X11 atoms or dcop calls to the app windows to allow 
integration in the applications that support it. KMainWindow can then 
automagically show and hide a tab bar as it sees fit, options like 'open in 
new tab' can be implemented easily, etc.

If the app is not compliant to this window manager extension then the window 
manager draws the tab bar itself as part of the window decoration, though of 
course you lose the integration and you end up with something like fluxbox 
here. That only applies to non-KDE apps of course since the KMainWindow-Kwin 
integration makes this instantly possible for KDE apps.

-- 
Martijn