WM managed MDI (was Re: Three different tab implementations)
l.lunak at suse.cz
Mon Feb 3 12:55:38 GMT 2003
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 :).
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/
More information about the kde-core-devel