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

[Neil Stevens]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday February 03, 2003 08:13, Lubos Lunak wrote:
> On Monday 03 of February 2003 16:50, Neil Stevens wrote:
> > 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.

I figured KStart was probably hackish.

Maybe we should start telling KWin about apps.  Yeah.  Maybe the only thing 
KWin really needs, in order to do MDI-like stuff, is to be told what 
windows are owned by which apps.  Then KWin could group a Gimp's windows 
together, or be asked by KDevelop to group a particlar KVim with KDevelop, 
and so on.

Though I'm beginning to think some sort of command-line option is going to 
be needed here, in order for child apps to be grouped with the parent 
MDI-ish app.  Surely a command-line option can be standardized, so that 
any app can be launched like so:  `kvim --group="KDevelop-13213" 
/home/neil/foo.cpp` and be put into the KDevelop-13213 group.  
KDevelop-13213 would be the window group started by the main window of 
KDevelop with pid 13213, of course.

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

But KDevelop *shoudln't* tell KWin how to manage windows.  If every app is 
responsible for its own management, we're little better off than we are 
now.

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

Universal MDI require anything not in KMainWindow or KApplication.  If you 
require apps to go and add MDI-specific things, then it will not be 
universal.  Or else SDI-fan developers won't use it.

And also, a universial *optional* MDI must be obeyed by an application 
developer.  If an MDI-fan developer does MDI in his app anyway, then a 
global SDI option won't have any efficacy.

- -- 
Neil Stevens - neil at qualityassistant.com
"Distinctions by race are so evil, so arbitrary and insidious that a
state bound to defend the equal protection of the laws must not allow
them in any public sphere." -- Thurgood Marshall
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+Pp2Hf7mnligQOmERAjvvAJsFJigcV2vMVA2yfEqflHGjHSoBwQCfRof7
4YwreDkrjEFa7+uIO91uSjY=
=ax8H
-----END PGP SIGNATURE-----