WM managed MDI (was Re: Three different tab implementations)
neil at qualityassistant.com
Mon Feb 3 16:49:11 GMT 2003
-----BEGIN PGP SIGNED MESSAGE-----
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
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
> 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)
-----END PGP SIGNATURE-----
More information about the kde-core-devel