Three different tab implementations
cullmann at babylon2k.de
Sat Feb 1 15:39:17 GMT 2003
-----BEGIN PGP SIGNED MESSAGE-----
> 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
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
> c) people using other window managers will have a jarring difference of
> look between the MDI window mangement widgets and their window manager
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
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 ;)
KDE Developer, kde.org Co-Maintainer
http://www.babylon2k.de, cullmann at kde.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the kde-core-devel