Three different tab implementations

[Christoph Cullmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Disadvantages of the lib approach:
>
> a) Users' wishes are ignored.  SDI fans get snubbed by MDI apps, and MDI
> fans get snubbed by SDI apps.
Windowmanager support won't turn a "mdi" app like konsole, konqueror, 
kdevelop, quanta or kate in to SDI neither, only tabbing of windows alone 
won't be enough for that apps, you completly ignore that all these apps need 
at least docking of windows (and konqui and kate need splitters) too. 

> b) existing apps must have their windowing code rewritten to use the
> MDI-lib
Same with windowmanager, as stated allready in previous mail, how should that 
work automagically if the apps allready have imbuild their own code to handle 
it ?

> c) people using other window managers will have a jarring difference of
> look between the MDI window mangement widgets and their window manager
> widgets.
Wrong. If the app undock its dockwidgets they can be handled by the WM, 
kdockwidget does it that way since ever, or ?

> d) non-KDE apps are left out entirely from the user's wishes.  Imagine if
> non-KDE apps couldn't be moved from one desktop to another.
? I have never said tabbing support in kwin would not be cool, but not as 
primary mdi implementation. And I don't think non-kde apps will be adjusted 
to rely or support the kwin tabbing modes.

> e) It completely ignores the root problem that turns some people to MDI:
> KWin, the task bar and other KDE services are failing people.
No, MDI is a must have if an app needs some more control about its windows. 
KDevelop for example needs to be able to arrange its dockwidgets and views in 
a very specific way or they will just clutter the whole screen, same for 
kate, quanta, ... Tabs in kwin will be cool for simple apps, where only some 
mainwindows come up, not conntected with each other and the user can just 
stack them manually via kwin. The reason for MDI use is as said: The app can 
control the windows in a sane way. Look at the splitter example: How do you 
want to teach a windowmanager the splitting in a sane way ? If you create two 
mainwindows, you get duplicated menubars/toolbars and so on which all have 
only half the space. Than you have to tell the wm to shrink the old window to 
half size, place the other window next to the old one, ..... Dockwidgets are 
even impossible without a lib (k, we have them allready in kdeui, no matter 
here, but as seen in qextmdi, they integrate very well into a mdi 
implementation).

K, only my personal opinion:

a) for real mdi you need a lib, no way around, the apps need real control 
about their windows/views and dockwidgets and they can't rely on having kwin 
as windowmanager, that is a no go for apps like kdevelop or quanta for 
example, which are often used outside the kde environment I guess. Just to 
let the wm stack the windows automatically is non-sense for a app which needs 
mdi (you would still need mainwindows, which kills any speed, imagine 
kdevelop, quanta or kate would open a whole mainwindow for each fileview, 
uhh, with all the plugins and xmlgui stuff to do on mainwindow creation that 
is NO speedy fun, for simple windows like the one of ksirc it is doable, but 
not for fat ones like in the mentioned apps).

b) the plan to enhance kwin with tabbing is kind of cool ;) I like the idea to 
be able to stack my windows (as on my 1 monitor there isn't that much space 
around ;) and I think users will enjoy it, too. But that is no solution for 
the mdi problem, it is only a solution for be able to handle a large amouth 
of sdi apps without changing their code or to get rid of the many windows of 
controlled sdi apps or how they are called (like the gimp). Perhaps even a 
mac style menu bar on the top of the screen would be doable, would like it, 
but that would be kde specific, too ;)

cu
Christoph

- -- 
Christoph Cullmann
KDE Developer, kde.org Co-Maintainer
http://www.babylon2k.de, cullmann at kde.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD4DBQE+O+ooyPjDGePm9UIRAvpUAJ0YM6gWWta4Z4baD32B0xYWI5wS9ACYsSlO
LBC3crigBz1Cnx/Z+R3UAA==
=MHSC
-----END PGP SIGNATURE-----