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