From kde-core-devel  Fri Jan 31 20:44:33 2003
From: Christian Loose <christian.loose () hamburg ! de>
Date: Fri, 31 Jan 2003 20:44:33 +0000
To: kde-core-devel
Subject: Re: Three different tab implementations
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=104404596910488

Am Freitag, 31. Januar 2003 21:08 schrieb Christoph Cullmann:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
> just my thoughts as kate maintainer:
>
> I would like more to have a generic mdi lib/implementation in kdelibs than
> messing around with the window manager. If we rely on windowmanager support
> for the whole mdi stuff, we will make it impossible to use KDE applications
> (which would use the mdi stuff, like e.g. konqueror, konsole, kate, quanta,
> kdevelop, ....) outside of kwm, as we can't enforce that other wm's get the

Hi Christoph,

I agree that not having the tab mode available under other WMs is a big 
disadvantage of the WM approach. But the lib approach has the disadvantage 
that you have to change every single app in order to provide a tab mode, 
right?

Also the lib approach doesn't provide non-KDE apps with a tab mode like the WM 
approach does.

> same mdi support ad hoc. And a implementation lib wise would still have
> many good sides: (as mentioned allready by others)
>  a) no code duplication

This also applies to the WM approach. I guess you can even remove a lot of 
code in those apps.

>  b) better GUI for the apps, as more consistent

This also applies to the WM approach and (like I said above) it provides a tab 
mode to non-KDE apps making the GUI even more consistent.

>  c) less possible errors for the app developers, as they don't have to mess
>      around with the internals, the classes could even hide some
> windowmanager magic later

Sorry, but I don't understand would you mean with internals, so I won't 
comment on this point.

>
> But assuming we would create such a lib, please not limit it to the "tabs"
> case. What we need is a flexible interface for apps to allow them to:
>
> a) have tabs for their views
> b) allow splitting of a window (that really rules over each window managing
> stuff atm, no rearragment of the other windows, just hit one key and you
> have your 2 views beside each other, fine and clean)
> c) allow the d'n'd of views out of the splitviews or tabs to become a real
> window
> d) allow docking of different views into one window (like seen in the
> konqui sidebar or kate or kdevelop)
> e) allow the apps to set sane defaults where everything is placed and let
> the user save his profiles he wants to have restored, that is something the
> current kdockwidgets only support very primitive (I think therefor
> kpovmodeler does use it's own version of them, or ?).
>
> The qextmdi lib allready tryed that approach (is in use in kdevelop) in
> parts. For the whole drag around and drop around stuff the kdockwidgets
> really are very handy, if they would be finally debuged and enhanced
> usability wise a bit more.
>
> If somebody comes up with such an implementation, I would go and use it in
> kate and replace my own mdi managment with it, as that is only a option if
> I loose no flexiblity.
>
> cu
> Christoph

greetings
Christian