Three different tab implementations
Waldo Bastian
bastian at kde.org
Sat Feb 1 16:28:13 GMT 2003
On Saturday 01 February 2003 16:39, Christoph Cullmann wrote:
> No, MDI is a must have if an app needs some more control about its windows.
> KDevelop for example needs to be able to arrange its dockwidgets and views
> in a very specific way or they will just clutter the whole screen, same for
> kate, quanta, ... Tabs in kwin will be cool for simple apps, where only
> some mainwindows come up, not conntected with each other and the user can
> just stack them manually via kwin. The reason for MDI use is as said: The
> app can control the windows in a sane way. Look at the splitter example:
> How do you want to teach a windowmanager the splitting in a sane way ? If
> you create two mainwindows, you get duplicated menubars/toolbars and so on
> which all have only half the space. Than you have to tell the wm to shrink
> the old window to half size, place the other window next to the old one,
> .....
Yes, you would have to teach the window manager all that. It is certainly not
simple to do that in a sane way, and I certainly think that it requires
modifications in and cooperation from the application involved 1) (except for
a very few simple cases maybe) But other than that I think it can be a big
step forward in usability.
E.g. the mac-os bar proves that it is already possible to split off the
menu-bar from the mainwindow. I don't see why the same can't be done for the
toolbar. Then it is only a matter of delegating the arrangement of
menubar/toolbar/mainwindows to the window manager.
In this light, let me quote an issue raised in a usability report on konqueror
by David Hugh-Jones <hughjonesd at yahoo.co.uk>, see 2)
Cheers,
Waldo
1)
Unlike Neil, I think that in order to support MDI-like functionality in the
window manager you need support from the application. So I think that in
order to achieve a WM-based solution you need to have library support for MDI
in the base libraries. That way it is much easier to delegate tasks at some
point in time from the application to the window manager, possibly after
detecting that the window manager does indeed provide the necassery features
for that.
2)
<issue severity="medium">
<title>
Window panes (views) don't respect window behaviour settings
WRT mouseover
</title>
<description>
If I change my window behaviour settings to "focus follows
mouse", I would expect this to apply to konqueror views also - the one with
the mouse in gets activated. However, konqueror views are always
"click-to-focus"
</description>
<reproduction>
<step>Change your window behaviour to "focus follows
mouse"</step>
<step>Open a konqueror window with two panes (views).
</step>
<step>Move the mouse over the panes.</step>
</reproduction>
<solution>
I suspect there are horrible underlying issues here, but if
possible, could we have views becoming active according to the window
behaviour settings? This actually also applies to e.g. Kate split windows.
</solution>
</issue>
More information about the kde-core-devel
mailing list