WM managed MDI (was Re: Three different tab implementations)
l.lunak at suse.cz
Mon Feb 3 16:13:38 GMT 2003
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
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
> > >
> > > 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
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