Three different tab implementations
klingens at kde.org
Sun Feb 2 14:51:08 GMT 2003
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
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.
More information about the kde-core-devel