Three different tab implementations
neil at qualityassistant.com
Fri Jan 31 11:33:31 GMT 2003
-----BEGIN PGP SIGNED MESSAGE-----
On Friday January 31, 2003 03:15, Waldo Bastian wrote:
> On Friday 31 January 2003 13:56, Jan Van Dijk wrote:
> > If tabs are considered Bad Practice, a note in the style guide may be
> > appropriate.
> The style guide mostly takes offense with MDI implementation such as Qt
> Designer where the application unnecassery restricts the placement of
> windows and imposes his own idea of a desktop on the user. Star Office
> is another example of such restricting interface.
> Tabs are a whole different class of MDI, they also restrict the user in
> the sense that only one document at the time is visible, but in this
> case that can be considered a feature assuming that the user has
> deliberately choosen to use this in order to better manage a substantial
> set of similar documents.
Tabs may be a whole different class of MDI, but every word you said in the
first paragraph applies to them equally well.
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.
> One could also argue that the desire to use the above mentioned forms of
> MDI comes from the lack of grouping facilities in the current generation
> window managers. But I don't think that's a very strong argument unless
> you can come up with a window manager that indeed manages to take away
> that desire.
But it's not a question of just accepting MDI or not, is it? There's more
being asked for here, and there are more options available:
a. Let developers do MDI on their own (ignoring it and wishing it would go
b. Develop a standard MDI system and port all MDI apps to it (what Rob
seems to be asking for here)
c. Develop a window manager spec for tabbing systems, and implement it in
KWin (likely involving, and benefiting from, GNOME and other window
manager developer input).
Right now we've had a). To me, if development is to be expended, c) is
better than b) because c) will:
1. Give MDI support to all apps (including SDI apps both KDE and not), for
fans of MDI
2. Give developers more reason to develop SDI apps, which will lead to SDI
available for those who prefer that interface style
3. Give KWin task-oriented features like it never had before, transcending
the app-centered MDI/SDI options.
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