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

[Lubos Lunak]

On Monday 03 of February 2003 16:50, Neil Stevens wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Monday February 03, 2003 07:34, Lubos Lunak wrote:
> >  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.
>
> I agree.  I think we need the ability to tell KWin that a group of document
> windows is related.  Then people who want MDI can flick a KWin switch and
> get it.
>
> How does kstart work (You've said that your thoughts are affected by
> knowing the window manager side of things, well, my thoughts are hindered
> by *not* knowing X window management).  KStart seems to manage to tell
> KWin that the app it launches should go on Desktop N.  Could something
> similar tell the window manager that App X is one of KDevelop's Documents?

 KStart is an ugly hack BTW, but yes, that's what I was trying to explain in 
short in the first mail in this thread. Maybe an important thing I forgot to 
mention was that WM doesn't know apps, it knows only windows, and it will be 
able to find the app or whatever more only if it will be able to find it out 
from the information the app placed on the window.

 So in order to get KDevelop use KWin for MDI managing, it would have to 
create the different windows as toplevel and mark them appropriately. The 
menubar+toolbar window would be simply marked as "hi, I'm the main window of 
the app", the C++ windows would be "my mainwindow is that window 
(=menubar+toolbars), and I belong to this and this group of windows(=all C++ 
windows of KDevelop)", and the listview would be "my mainwindow is that 
window(=menubar+toolbars)". 

 KWin would see that, and would e.g. decide to place the mainwindow ... erm 
... somewhere, the listview window right below it with left edges aligned, 
and, since the user has as a preference e.g. tabbing, it would tab together 
all the C++ windows, and place them below the mainwindow and on the right of 
the listview window.

 The slight problem here is that it could place the windows also differently, 
say, the project listview below all the C++ windows, which is a bit dumb. 
This is actually the very thing I wanted to hear from you WRT KDevelop - how 
to make it tell the WM the arrangement of the various windows in some sane 
way.

[snip]
> > >
> > > 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.).
>
> The convincing thing, the reason that convinces me, should be that we'll
> never get an MDI and an SDI version of every app.  A big reason being
> we'll always have developers like Falk or I that have a strong preference
> one way or the other.

 But a flexible universal MDI will require a lib, be it handled by the lib 
itself or the WM. The lib may allow you to configure it so that you'll get 
all tabs automatically undocked as toplevel windows even if it implements the 
MDI all on its own. This one isn't a very good reason why it should be the 
WM.

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