From kde-core-devel Sat Feb 01 15:39:17 2003 From: Christoph Cullmann Date: Sat, 01 Feb 2003 15:39:17 +0000 To: kde-core-devel Subject: Re: Three different tab implementations X-MARC-Message: https://marc.info/?l=kde-core-devel&m=104411400629912 -----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@kde.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD4DBQE+O+ooyPjDGePm9UIRAvpUAJ0YM6gWWta4Z4baD32B0xYWI5wS9ACYsSlO LBC3crigBz1Cnx/Z+R3UAA== =MHSC -----END PGP SIGNATURE-----