Three different tab implementations
Josef.Weidendorfer at gmx.de
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
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
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
(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
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
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
More information about the kde-core-devel