Three different tab implementations

Josef Weidendorfer Josef.Weidendorfer at
Fri Jan 31 14:35:31 GMT 2003


just some thoughts on this...

On Friday 31 January 2003 13:48, Andras Mantia wrote:
> On 2003. January 31., Friday 13:33, Neil Stevens wrote:
> > And unfortuantely some MDI apps in KDE do not give the user a choice
> > choice.  KDevelop and Quanta come to mind.  There it is MDI or nothing.
> Ok, let's take this a feature request. :-)  How would you like to behave
> those applications:
> a) when opening a new file fire up a new instance of the application, load
> again the whole project that you are working on and open the file there

Yes. Thats SDI: Opening a new window. Inside the same process of course;
surely it doesn't involve loading the project again.

> b) close the file that are you working on and open the new one instead of
> it

In SDI, closing a file means closing a window. And a window is closed using 
the window manager. The application shouldn't do this on its own.

> c) ...
> I'm waiting for your opinions. I really don't see why it is bad to have MDI
> in this case and in this form. I find it to be easy to use and user
> friendly. Of course we can make an option to use SDI instead of MDI, but
> the question is the above one: how to use SDI?

SDI involves many open windows. I think that current WMs don't handle this 
quite well.
There should be a possibility to 
(1) stack windows, using a tab bar above the window to let you choose a window 
to raise to the top of the stack. This is what FluxBox or PWM 
( does.
(2) group windows. This means that windows stick to each other when moving one 
of them, and to resize if needed. This is what Konqui does with "Split 
View...". Example for a window manager using stacking and splitting: Ion 

For tabbed/stacked windows the WM should allow you to configure the maximum 
number of windows, and let the WM close other stacked windows e.g. using a 
LRU scheme.
For grouped windows, it should be possible to only show the title of one 
window for the whole group.

Suppose a Konqui with a toplevel window only consisting of the Menubar, 
Toolbar, location bar. And other toplevel windows for each browsed document.
With stacking and grouping you pretty much would get the GUI of the current 
tabbed konqui.

Things to be added to a window manager spec:
(1) On opening a new window, let the application optionally decide on where to 
place this window: Either a new toplevel frame, or a new stacked window 
attached to another open window, or a new grouped window attached to another 
window (on left/right/top/bottom side). The application should be able to 
request the placing method the WM allows.

(2) Allow for grouped windows to get notifications if the focussed window has 
changed inside of the group. This will allow the top Konqui window in the 
example above to update the location bar.

Regarding the implementation, grouping should be possibly using window names 
and window class names. Focus notification inside grouped windows are regular 
X events. For placement policies of new windows, setting a window property 
should be OK.

To be acceptable for the average user, there should be default window profiles 
for applications like Konqui/Kate/KMail ... to make everything fully 
automated. This way, the end user even doesn't see any difference to what the 
applications do today. And the advanced user can stack/group the windows to 
his liking.


More information about the kde-core-devel mailing list