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

[Lubos Lunak]

On Monday 03 of February 2003 14:54, Neil Stevens wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Monday February 03, 2003 05:39, Lubos Lunak wrote:
> > On Monday 03 of February 2003 14:16, Neil Stevens wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > On Monday February 03, 2003 04:55, Lubos Lunak wrote:
> > > >  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).
> > >
> > > What would KDevelop need to do to my text editor?  I can't say more
> > > unless Iknow what you're looking for.
> >
> >  I suppose the windows for C++ files should be organized in some way. If
> > every new window with C++ file will be simply "shown somewhere", then I
> > think it's much better to use tabs inside of KDevelop which will place
> > it so that it doesn't cover other important windows yet it takes as much
> > space as possible. What exactly is the WM way going to buy me if the WM
> > does a much worse job at placing the windows, since it won't know how to
> > place them correctly (and it won't, as long as there won't be a way how
> > the app will tell it)?
>
> I'm sorry, I don't think understand you.  How can a window *not* be "shown
> somewhere?"  Do you want KDevelop-related editors to be restriced to a
> portion of the desktop or something?  Child window MDI without the parent
> window?

 By "shown somewhere" I meant simply shown in some place, without any relation 
to things around it. If I run KDevelop, and I want to have the project 
listview visible on the left of the C++ windows, just showing them (=C++ 
windows) won't do a good job. You maximize the C++ window -> the project 
listview window gets hidden. You make the project listview a bit narrower -> 
C++ window won't move and resize to use also that additional window. This 
wouldn't happen with tabs.

 If you want to get MDI support from the WM, not just the fluxbox-like ability 
to group some windows together, you need to tell the WM more than just 'this 
is a window'. If you don't, you'll just have a bunch of unrelated windows 
which you'll have to manually manage yourself.

 View splitting in Konqueror is a much better example of this. Say that you 
simply decide to let the WM manage the two new views, so you just unmap the 
old window and map two new ones, together taking the place of the old one. 
Guess what - the WM, unless including a crystal ball feature, won't find out 
there's any kind of relation between the two windows. You can drag the 
splitter between the two views in Konqueror, but in this example, you'd have 
first to shrink one window, and then resize the second one.

 It could work with WM too, it's just that the WM would have to be told the 
relation between the two windows. Somehow. And this 'somehow' was what I was 
trying to find out, without realizing I possibly see the whole thing 
differently. I don't know what exactly people in this discussion meant 
(http://lists.kde.org/?l=kde-core-devel&m=104414112521454&w=2), but I think 
that if you want the WM help you organize the window on the desktop, it needs 
to be told how.

 BTW, I personally don't find just placing the windows in the "right" 
positions to be the way it should be done, and I don't think I'd want to play 
that game. First of all, that's avoiding the WM, and if you want to abuse 
things, you can as well do completely without the WM. Second, it simply won't 
work, for example just move some window, and the "right" positions will be 
suddenly wrong.

>
> Oh, tabs *don't* place windows.  They completely gives up the notion of
> window placement, and destroy the ability to see more than one document
> simultaneously.  So how can that be better than what KWin can do now?
>
> Do you believe that KWin is hopeless for document management?

 I'm not sure what you mean exactly with this. I think KWin could handle MDI 
instead of the apps. The question is, how good job it will do, compared to 
apps taking care of it themselves. See the description of a MDI library
http://lists.kde.org/?l=kde-core-devel&m=104404380507514&w=2 , and tell me 
what the WM could do better than such lib would do. I can think of some 
advantages, like focus follows mouse working the same for everything, but 
right now I can't come up with something really convincing, especially given 
the disadvantages (WM supporting it is needed, etc.).

-- 
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/