WM managed MDI (was Re: Three different tab implementations)

[Lubos Lunak]

 Ok, let me comment a bit on the issue:

 First of all, I don't see any fundamental reason why the WM couldn't be able 
to handle tabs or similar things. There wouldn't be any messing with widgets 
hiearchy or anything similar. As Waldo pointed out, if you want to see a 
widget managed by the WM, just in the 'Style' kcontrol module enable the 
standalone toplevel menubar.

 Let me explain a bit how the WM actually works. I think that the idea is that 
in an ideal world, the application is allowed to do only 4 things: Map(=show) 
a window, unmap a window, set some flags on a window (so-called hints), and 
_try_ to resize a window. I hope I didn't miss anything important (no, I 
didn't forget activating a window, it doesn't belong there). Of course, the 
reality differs a bit, partially because the WM cannot do something the app 
developer wants, but it's mostly simply because the developer has no clue 
about how it should be. And the way it should be is that the WM handles 
everything window related.

 The app and WM communicate using the hints on the windows, and some messages. 
So the app, before mapping a window, sets a couple of hints on it, describing 
the window, maps the window, and the WM is supposed to take care of the rest. 
See, for example, the various tool dialogs in Gimp. I just tried them, and 
they really appear in weird positions, I even can't guess what the rule for 
their placement is. If done as described above, Gimp should just set hints on 
the tool window to say 'ok, WM, this is a tool window, its mainwindow is that 
one, and please don't make it smaller than 200x100'.

 WM will see that window about to be mapped, will read the hints, and will go 
like this 'so, this window has a mainwindow, ok, that means I'll keep it 
always above the mainwindow; it has a minimum size, so I won't tell the user 
make it smaller, and finally, it's a tool window type, so the user will 
mainly work in the main window, but will need this tool window from time to 
time, so won't place it above the center of the main window, but I'll place 
it somewhere where it doesn't get in the way, preferably next to the 
mainwindow, where's some free space'.
 
 This has advantages like the WM knowing the situation on the desktop much 
better then the app, being better at handling user's preferences, and so on. 
Of course, as long as the app is not abusing some means that meant for few 
apps that really know better than the WM, or meant mainly as user preferences 
(e.g. the StaysOnTop flag - almost no app should set it, and my plan is to 
get rid of its usage as part of the KWin rewrite). If the app explicitly asks 
to place a window somewhere, the WM has no chance to check if the developer 
is lame or not, and simply has to obey.

 Now, WM managed MDI. In order to let the WM manage various windows, they'd 
have to become toplevel windows. Perhaps the WM could be made to handle 
windows inside apps, but I don't feel like trying how much could that break. 
So e.g. KDevelop should do like e.g. Delphi does, see e.g. 
http://www.drbob42.com/kylix/hotshots.htm , with the menubar+toolbars forming 
one window, treelist with project files as another window, and the various 
windows for C++ etc. files as another windows.

 It, however, doesn't mean it would have to look like in the Delphi 
screenshots. It could be very well made that the WM will take all the C++ 
files windows, put them inside one tabgroup, will draw only a small (or maybe 
even none) titlebar for it, place this tabgroup right below the 
menubar+toolbar window, and place the project treelist left from it (so that 
it would look exactly like it does now :) ). But that would be only one of 
the ways to organize the windows. Other could simply have them as standalone 
windows, let the WM tile them inside some area, or maybe even such crazy 
things like one Konqy window added as one tab. Note that the app would of 
course have to help the WM with this by telling it the relation between the 
various windows, which could possibly get a bit complicated.

 Now it would be perhaps good idea to ask Neil to describe this KDevelop thing 
in more detail. I'm affected by knowing the way WM works, and perhaps also 
limited by this, so maybe there's a better way of doing it. It would be good 
to hear how KDevelop should look like and work from somebody who doesn't know 
the internals. So, Neil? (The Cervisia example isn't that good, it simply 
starts new editor for every file - KDevelop needs more than just this). 

 Feel free to ask if you have questions. I don't want to go into more details 
before getting a more precise picture of what you want. Since I have 12 
virtual desktops and use apps strictly as SDI (except for KSIRC tabs), it's 
not easy for me to imagine how the current implementation should be improved, 
given that I don't use it.

 Maybe one more thing, I could try to list (dis)advantages:

- It would obviously need a WM capable of supporting this. Since KDE apps are 
often used also outside KDE, it would be a problem if it didn't work at all 
without the supporting WM. I'm not sure how bad it would be without the 
supporting WM. Perhaps it would be unusable, maybe some features could be 
simply disabled and it would still more or less work (e.g. KDevelop would 
simply feel like Delphi).
 
- There would be a library (or let's rather say some lib code) needed for 
handling this. I'm afraid developers would much prefer thinking of windows as 
of tabs and not 'I have to place a property here and there, and watch for a 
message here'. If the library didn't try to provide the same functionality 
also without a supporting WM, this code could be quite simple I think.

- Requiring WM support would make two processes involved, which always 
complicated things at least a bit. There could be small performance decrease, 
flickering and similar stuff (and maybe not, I don't know yet).

- There aren't that many people who both have the time and knowledge to mess 
with KWin code. Moreover KWin is currectly undergoing a rewrite (hmm, is that 
a problem or an advantage?).

- Apps would have to be nice and behave correctly, no abusing of things. Refer 
to what I've written above. If the app would decide from time to time that it 
actually knows better, it can as well do it itself completely.

Hmm, I think I could list more disadvantages if I tried harder, but I'm having 
problems finding some (good) advantage of the WM approach when comparing it 
to the lib solution, if the lib would allow undocking a tab as a standalone 
window, and docking it back (only in the same app obviously). Ok, besides 
being theoretically a nicer cleaner blah blah solution. Somebody help me :).

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/