Window managers with workspaces vs. Windows MDI

Posted 7 Jun 2001 at 14:51 UTC by Raphael Share This

Several applications that are ported from X to Windows get the same kind of comments from Windows users: "It would be nice if the application could put all its windows into a single big window, like most other Win32 applications do." The reply is usually: "You need a better window manager." But is this the right reply? Maybe something could be done when porting the applications...

This issue appeared (again) recently on the Gimp developers mailing list (look for the thread titled "GUI comments from and NT user" in the mailing list archives). While writing a message for that discussion, I thought that it would make an interesting article for Advogato, so I re-edited my comments and here is the article...

Frequently, some Windows users complain (or make polite suggestions) about the fact that an application ported from UNIX to Win32 opens several top-level windows instead of using the MDI model that is used by most Windows applications. An application using the MDI model (Multiple Document Interface) can open many sub-windows inside a main window and these sub-windows are managed like all other windows, but they remain inside their container. The container window can provide a menu, a status bar, and also prevents the user from clicking accidentally on a window from another application.

Most of the applications ported from X do not have an MDI interface and this causes some problems for Windows users when they have several applications open. This is usually not a problem when the application is used in a native X environment, because all modern window managers provide separate workspaces or virtual desktops in which the user can group the windows in a convenient way. Therefore, the usual reply from X developers who get these requests for MDI interfaces from Windows users is that they should get a better window manager, and this feature will not be implemented by the application itself because this is really the task of the WM. The discussion usually ends there, but comes back again from time to time.

In fact, the Windows way (using MDI) and the virtual desktops are two slightly different solutions to the same problem: grouping windows belonging to the same application, or windows that are related to some specific task.

  • In X, the solution has been implemented at the WM+user level: the applications create lots of independent windows, and the WM provides several workspaces in which the user can keep these windows together. Since X does not enforce any UI policy (this is a feature), different WMs provide slightly different options for these workspaces, but the basic principles are usually the same.
  • In Windows, the solution has been implemented in the built-in WM and in the libraries that can be used by all applications: there is a set of functions for generating MDI interfaces, and the applications that want to use this system can have their sub-windows managed inside a big top-level window. A few additional parameters in some API calls are usually enough to create an application using the MDI model.

In the end, the effect is very similar: things that belong together can exist in their own environment (workspace or top-level window) and the user does not accidentally click on a window that is in the background and belongs to another application. The X solution is more flexible because the user can choose how the windows are grouped (e.g., having several applications on the same workspace, or the windows of a single application spread over several workspaces) instead of having this choice made for them by the application developers. On the other hand the Windows solution is easier to use for many users and it has some advantages too: a common menu bar and status bar can be used for all document windows, and this takes less screen space than having them duplicated in each window. The old MacOS system had an even more radical approach: there was only one menu bar at the top of the screen, showing the options for the application that was currently "on top".

So there is a general problem with many X applications that are ported to Windows. Since most of the Windows applications use the solution that is already provided by the system (multiple windows in one big window), there is no need to use a WM that provides several workspaces. It is therefore natural for the users of the ported applications to criticize the developers for not using the facilities that are provided by Windows. Sure, a WM providing several workspaces could help the Windows users, but why should they be forced to use this because of only one application that does not behave like all others? Note that such WMs exist but they are mostly used by those who have to run many X applications under Windows. Most other users would rather complain to the developers and suggest to use an MDI interface.

I don't think that the debate is going to end soon because both systems have pros and cons. Both camps can argue about this or that, but things are not likely to change because each system has its own philosophy and in the end the best solution is probably to behave like most other applications behave on each system. So here is a proposal: integrate an MDI option in the Windows port of GTK+. (I am suggesting this for GTK+ because Qt/KDE already looks very much like Windows and there are different issues related to the Windows port of Qt applications.)

The Windows port of GTK+ could include a mini-WM that produces the same results as the usual MDI applications (or uses the Win32 API calls to provide this feature). This would be optional, so that the users who already have a decent WM or who are satisfied with the multiple windows would not be forced to use the MDI model. But for the majority of users who are not interested in changing their environment for a single application, this could be very helpful. In its simplest form, the top-level window could be just a frame without a menu or status bar. For some applications, it may be possible to reparent some parts of what is considered as the main window and to attach these directly to the top-level window.

If such a feature was available in the Windows port of GTK+, then each GTK application ported to Windows could run with all its windows grouped inside a top-level window, if the user likes this option. Note that doing this only in the Windows port would simplify some problems that are hard to solve in X, such as how to emulate the look and feel of the WM, since the choices under Windows are rather limited. It is very hard to apply the MDI model to an X application because it is impossible for an application to emulate the features of all different WMs that are available. It is even possible to switch to a different WM while the applications are running, which would be hard to detect from the application. But this is easier to do in the Windows world, and this could be a nice addition to GTK+.

connected browsers (JBuilder), posted 7 Jun 2001 at 15:27 UTC by mvw » (Journeyer)

I agree with the part that MDI is a consequence of the single desktop paradigma with the effect of grouping windows.

Another style that seems to work nice is the connected browsers style (I don't know a better term :), which is used by JBuilder 4.

Each browser window manages some child windows in a tabbed pane widget, selection by the ubiqitous tree view. On the other hand one can open a couple of browsers and you can navigate from one browser to the other. (Emacs has similiar with its different frames).

Extending GTK+ for Win32 would be great, this projects deserves more resources.

Regards, Marc

Note that MDI is going away, posted 7 Jun 2001 at 15:43 UTC by AlanShutko » (Journeyer)

Not even MS is using it anymore in Office 2000.

Do we really want to spend time supporting a paradigm that's on its way out anyway?

Re: Window managers with workspaces vs. Windows MDI, posted 7 Jun 2001 at 17:05 UTC by mslicker » (Journeyer)

You could probably extend the question in general to "Should an application behave the same across platforms, or should it adapt to the UI and features of a particular platform?"

Personally, I like the latter. But here it's a bit tricky since gtk+ is platform of it's own, which runs on top of the native toolkit. Since you've already broken platform consistency, you shouldn't feel obliged to follow the conventions of the system. However, here the window system is limited in it's custimizability, and if adding a MDI viewport will help the users of that system, then why not?

I never actually use multiple desktops in X, posted 7 Jun 2001 at 17:07 UTC by Talin » (Journeyer)

I find that I never actually use the multiple desktop feature in X - I'm just in the habit of navigating through multiple windows via clicking on the window, or using the task bar.

This works well for most apps, i.e. netscape, emacs, console, etc. Well enough that I never developed the habit of arranging my windows on different desktops.

However, for me, GIMP is just as much of a pain as it would be for a windows user.

Part of the reason for this is that in most applications that support multiple windows, each window is a complete conceptual interface - i.e. you can use a netscape window without having to bring the other netscape windows to front. And, there's an easy way to bring the other windows to front if you need them.

With GIMP, however, you generally have 4-6 windows that are involved with a single document. If you bring another app to front (say, Konquerer), and then you want to edit your GIMP doc again, you have to individually bring all of those windows to front again.

I can think of several ideas that would make GIMP more convenient:

1) Bring all the GIMP windows to front as a group.

2) Put a copy of the GIMP tools in the border of the document window, so that the toolbar isn't a separate window.

3) As suggested in the post, make an MDI-like interface.

Re: I never actually use multiple desktops in X, posted 7 Jun 2001 at 19:42 UTC by eMBee » (Journeyer)

Window Maker handles all windows of an app as a group.
double-clicking on the app-icon will bring all windows of an app to the front, making it very easy to switch.
you can also hide the whole app at once making all windows disappear and only the app-icon remaining.

so all the functionality needed to create MDI under X (if you really want that) is there. the window manager can detect which windows are part of an application. so you could create an MDIwm which opens a large window for each app, and stuffs all the other windows inside that.

greetings, eMBee.

How does window manager know which window belongs to which app?, posted 8 Jun 2001 at 03:01 UTC by jwalther » (Journeyer)

I've been searching to the answer for this awhile. Mandrake said a while ago that it was solved in E, but didn't go into specifics. Does one really have to do something as ugly as an lsof to find processes connected to the X server? This assumes of course there is an X protocol call that tells you the remote connection information for any particular window. Does that exist? If it does, please tell. I'm drooling to do some cool stuff with this info in ratpoison, vis-a-vis virtual desktops, "application groups", automatic window renaming, and the like. Even this would break down if the remote endpoint was on another machine, which chose not to run identd. *sigh* Or is there some magical way I'm missing out on?

Re: How does window manager know which window belongs to which app?, posted 8 Jun 2001 at 08:19 UTC by Raphael » (Master)

There are various ways for the window manager to know which window belongs to which application. Every window created by an application has a number of (usually invisible) properties attached to it, such as its class, title, and other hints like "transient for". These can be used by the window manager to decide if these windows belong to the same application or not.

If you want to see some of these properties, you can run xprop from a terminal window and then click on any window on your screen. This will display a number of properties. Look for example at WM_CLASS and WM_CLIENT_LEADER. If you start the Gimp and click on some of its windows, you will see that all of them share some properties.

Re: I never actually use multiple desktops in X, posted 8 Jun 2001 at 09:34 UTC by Raphael » (Master)

Talin writes:
However, for me, GIMP is just as much of a pain as it would be for a windows user.

Part of the reason for this is that in most applications that support multiple windows, each window is a complete conceptual interface - i.e. you can use a netscape window without having to bring the other netscape windows to front. And, there's an easy way to bring the other windows to front if you need them.

Indeed, this problem is probably worse wih the Gimp than with many other applications, but several other X applications suffer from the same problem. For example: xv, xmms, crossfire and even the old xman. Some of these applications have features that help the user: xmms lets you drag all windows together, crossfire offers a single-window mode by default and the split mode is only an option. But it would be hard to use the same tricks in the Gimp.

Most of the Gimp developers and contributors (I'm one of them) use a window manager that offers virtual workspaces, so they see no problem with the way the application works. This is why the usual reply to the complaints about the multiple windows that are hard to manage is: "get a better window manager". When you have used a window manager with multiple workspaces for so long, it is hard to think about the problems that are encountered by those who are still having all windows on a single workspace.

Some of these problems might be solved in the next major release of the Gimp, which will allow you to group several windows (brush selection, pattern selection, etc.) in a single "dock". But there will still be a problem with the multiple document windows and the fact that the toolbar will be a separate window. Note that you can already solve a part of your problem now: pressing the Tab key several times will hide and show the toolbar and other windows. This could make it easier for you to bring all windows to the top.

Funny..., posted 8 Jun 2001 at 13:49 UTC by Fyndo » (Journeyer)

Even not using virtual desktops, I like the gimp many-windows interface, makes it easier to mix tasks (save gimp image, use terminal to scp up to web server, while discussing changes on irc). I can remember where I put all my windows, so finding them again isn't a problem. MDI type setups make this sort of switching harder.the finer-grained the units that the app puts on my screen, the more flexibility I have arranging them.

GIMP needs improvement, but not MDI, posted 8 Jun 2001 at 14:08 UTC by fc » (Master)

Lets start with some additions to how applications work under X:

  • A well behaving application under X uses its application name in all windows it creates. Actually, in all window headers (in the hope that all application users use a WM which decorates the window with a window header, and that the WM uses the hints).

  • A very well behaving application under X uses its application name and an instance number in all its windows.

  • Other applications simply prevent to be started more than once, but instead open a new window from the same application for every start attempt. Which is ok, if the application is rock-solid...

  • The most horrible application GUI one can have on X is one with an MDI interface. Usually applications ported from Windows to X come with such beasts. The MDI application was already bad on Windows, now it is even worse under X. So the problem MDI vs. SDI works both ways.

But now to the real problem: MDI (please bear with me, since I hate MDI applications from the deep of my heart)

There was a time when even Microsoft recommended in its GUI design guidelines not to use MDI any more (if my memory serves me right, that was around 1996). They didn't recommend it any more, for the same reason people don't like MDI: It reduces their freedom on how to deal with a very limited resource - the screen.

The only useful mode in which many MDI applications can be run is to enlarge the base window, so that it takes up the whole screen. Effectively, this results in a GUI usage mode of one application at a time only. And this is the mode "power users" probably hate most.

But not only that MDI is bad, there has been an incredible abuse of it in Windows applications. If you want to blow up a menu or a task bar beyond all proportions, use icon "documents" instead.

But some strange thing happened after MDI was "banned" and Windows applications where changed. It turned out that a large user base (among them Office product users) were fully adapted to MDI. Microsoft e.g. changed Word back to an MDI interface in Word 2000, because of so much user complains (and it takes a hell of a lot of complaints to convince Microsoft to change something...).

So here we are with a GUI paradigm that is horrible inefficient, but has a huge user base "addicted" to it. Hmmm...

I don't think the case can be argued on technical ground only. So maybe the decision boils down to be promiscuous and give the unwashed-masses what they want, or stay clean, and give the people what is good for them.

If I would have to have any say in the decision, I would not port GIMP to an MDI interface. My feeling is, there is more important work to do first. I would like to see major parts of GIMPs GUI reworked. I have to confess, whenever I have (and I mean have) to use GIMP (under Unix, of course), I am not a happy camper. It takes me ages to find functionality which is there in GIMP, but not where my limited mind-set would expect it.

Changing GIMP's user interface should not be based on a decision MDI vs. SDI, but usability. There is definitely room for improvement in GIMP.

Re: GIMP needs improvement, but not MDI, posted 8 Jun 2001 at 17:37 UTC by Raphael » (Master)

fc writes:
So here we are with a GUI paradigm that is horrible inefficient, but has a huge user base "addicted" to it. Hmmm...

That's the point. As Unix/X users, we can argue forever about how bad the MDI model is, this will not help much: there will still be a large number of Windows users who will think that the multiple windows are hard to manage, take a lot of space in the taskbar, make it too easy to click accidentally on other applications, and so on... Of course, when posting this article I expected that most X users would say that MDIs are cumbersome and restrict the users' choices. But the Windows users have a different opinion: many of them are used to these MDI applications and they like them (or at least they do not hate them).

This is why I suggested an optional MDI mode for Windows only. This is where it would be the most useful (most X users would not like it anyway) and it is also easier to implement in Windows than in X.

I would like to see major parts of GIMPs GUI reworked. I have to confess, whenever I have (and I mean have) to use GIMP (under Unix, of course), I am not a happy camper. It takes me ages to find functionality which is there in GIMP, but not where my limited mind-set would expect it.

The user interface of the Gimp is being reworked for version 1.4, and will probably be improved again for version 2.0. Several windows will be "dockable" and will be easier to manage. Recently, there has been a discussion on the Gimp developers mailing list about how the menus could be re-organized. But if you (or anyone else) think that the interface could be improved, then please submit an improvement proposal to Bugzilla. This is the best way to get an improved user interface in the next version (well, the best way is to submit patches, but some good ideas would already be useful).

You can also look at the existing proposals for enhancements for the Gimp, or look at all bugs that have been submitted regarding the user interface. Several improvements have already been suggested, but none of the developers had enough spare time to work on them yet.

Clarifcation, posted 8 Jun 2001 at 19:19 UTC by mslicker » (Journeyer)

The Gimp in X is a MDI interface just not a very strict one. Window managers are given a lot of freedom in how they treat windows, so they could just as well put all windows in their own work space for a MacOS style MDI, or put all windows in another window, I believe, for a MS Windows style MDI, or leave it as default for an OS X style MDI.

It all depends on the hints given to the window, how the window manager treats them. The window manager spec here defines _NET_WM_WINDOW_TYPE_TOOLBAR,_NET_WM_WINDOW_TYPE_MENU, _NET_WM_WINDOW_TYPE_DIALOG, _NET_WM_WINDOW_TYPE_NORMAL as window types. Combined with a transient hint, these grouped windows could be considered a MDI interface.

One nice thing to have for an OS X style MDI is a "Bring all to front" command to raise all the windows, as eMBee notes Window Maker has. I believe OS X also has this command.

Note: I've never used OS X, I've only read some documents, and I rarely use the older MacOSes, so my details might be a bit off.

Win32 Massively Discombobulating Interface (MDI), posted 8 Jun 2001 at 22:31 UTC by Ilan » (Master)

Many user interface people have criticized microsoft for the window-in- window MDI, including Tog (see 07ReaderMail.html#Anchor2 ). If you want to experience true user interface hell, try writing lots of code in the Visual Studio visual basic IDE. The MDI is bad enough, but then you've got to deal with those toolbars that dock with the window in the most aggressive manner possible. Sure, you can turn the "feature" off, but like most microsoft programs, configuration options for annoying stuff are scattered throughout the entire program. But I digress.

The MacOS solution is actually the most sane approach, because the menu is always in the same place (the top of the screen), which does away with the menu management problem. The MacOS menubar also sits on a screen border; and in accordance with Fitts' Law, all things that sit on a screen border are infinitely large and thus possess faster access times than things put on a window (because a border is impossible to overshoot). Studies show the MacOS menubar to be up to five times faster to access than the menus in Windows. While the contextual menu is technically faster than the global menu bar because it appears right under the user's pointer (WindowMaker wonderfully exploits this phenommenon), it's starts getting unfeasible and nasty when you have multiple-level contextual hierarchical menus like in Gimp and Dia. Those two applications are really the poster boys for replacing the foo bar widget with a global menu bar.

Education, not retardation, posted 9 Jun 2001 at 02:51 UTC by aaronl » (Master)

If the unwashed masses don't know how to manage windows, maybe they should learn? I love virtual desktops and couldn't live without them. The best service that can be done to an ignorant Windows user is to teach him the glory of better solutions.

Mac OS menus, posted 9 Jun 2001 at 12:40 UTC by Fyndo » (Journeyer)

The MacOS solution is actually the most sane approach, because the menu is always in the same place (the top of the screen), which does away with the menu management problem. The MacOS menubar also sits on a screen border; and in accordance with Fitts' Law, all things that sit on a screen border are infinitely large and thus possess faster access times than things put on a window (because a border is impossible to overshoot).

Personally, I disagree. The problem with the MacOS menu bar is it's system-modal. This conflicts quite badly with focus-follows-mouse, and generally, with performing tasks across 2 applications. That is, what is on the menu at the top of the screen depends on what application you used last, which is not necesarially the application you're looking at. If you have focus-follows-mouse, then it is the application the mouse pointer is in, which is likely to be the one you're looking at/thinking about, but to use the menu requires leaving the window, which may cause a focus change. Especially if you use all your screen real estate, like I do.

The fitts law analysis assumes single program use. If you imagine, for the moment, cutting and pasting between 2 different apps, w/o the benefit of any accelerators, the sequence goes something like:

  1. Start in window 1
  2. move mouse to top of screen to access menu, and select cut
  3. move mouse to window two, click to select window
  4. move mouse back to top of screen to select paste
Yes, Fitts law says that "infinitely large" areas are easier to hit, but also the distance moved figures in, and while using a single application at a time it pays off, if, as I do, you mix applications a lot, then it's adding confusing modality, and not gaining a great deal because you can't use the more efficient focus-follows-mouse and still hope to get the right menu when you get up to the top, and the distance from the bottom-most window on my screen to the top is non-trivial.

Where possible, I greatly prefer the right-mouse contextual windows, although they do get hairy when they get deep, but then, so do menus on a global menu bar. Clearly, a better solution to multi-level menus in general is what is wanted. Tear-off menus are a good start, since at least commonly used menus can be readily accessed. User configurable menus (being able to drag menu items around to create a top-level menu of your most frequently accessed operations) would also help.

MDI can be useful when done sanely, posted 9 Jun 2001 at 15:14 UTC by grib » (Journeyer)

I am responsible for the use of GNOME MDI in GnuCash, and I have no regrets about it at all. I have never used either Windows or the Mac OS for more than a couple of weeks at a time so it's not a Windows hangover; I just like having the option to have top-level windows get stacked in a tabbed dialog.

I realize that it's not exactly the same as Windows MDI, where every window gets stuck in the top-level playground; GNOME MDI give the developer the option to put whatever you want in there, and in GnuCash we only put 2 kinds of windows in the MDI system (tree views of your GnuCash accounts and HTML reports, which are both instances of a view of your financial info in some sense).

Also, GNOME MDI lets you grab the window's tab and drag it out of the main window to make a new top-level window, which itself can have multiple tabbed top-levels, and you can drag and drop tabs between top-level windows. And if you want each top-level in a separate window, you can do that too by setting MDI mode to "everything gets a top level" in gnomecc or in the application.

This isn't a window manager function because there's too much app-specific management that needs to be done to let the application be ignorant of what's going on. For example, in GnuCash each top-level window can have a different toolbar; only the currently-active tab's toolbar is displayed in any top-level window, and that has to be managed in the app. Menus change depending on what child is active too.

The idea of allowing users to better manage the proliferation of windows on the desktop is a good thing. Workspaces are nice for some things, but there's a point when that whole train of thought moves from "making space for more useful stuff" to "making room so applications can waste space". I like the ability for me to have a dozen different financial reports open in GnuCash without having to have my desktop look like my actual desk, which is 6 inches deep in paper.

Bill Gribble
Linux Developers Group

Re: Mac OS menus, posted 9 Jun 2001 at 20:47 UTC by mslicker » (Journeyer)

Fitts's law is something like:

time_to_hit_target ~~ target_distance / target_size

where ~~ means proportional to

Theorectically, on a finite display, the global menu always beats the window level menu, and the context menu always beats the global menu.

For copy and paste, I'd agree it seems awkward to point your cursor to the top of the screen, however it seems almost equally awkward to point your mouse to the top of a window.

Better than both of these methods is either a context menu, X's middle click paste, or a mouse/keyboard short cut.

The reason I like the global menu and global things in general, besides Fitt's law, is it just gets rid of screen bloat. While it's certainly useful to have multiple windows open, when I'm using another window, I don't need each windows toolbar or menubar or scrollbar. It' simply useless redundant information on the display. While most times I don't use every square inch of my screen, I like to get rid of as much distracting information as possible, so bare space to me, is more useful then excess menubar/toolbar/<insert you favorite widget here> space.

Let the WM handle it, posted 10 Jun 2001 at 03:45 UTC by carmstro » (Journeyer)

The most obvious solution to me is to use a wm (or make one, if one doesn't exist) that has the option of putting a "workspace" into big container window. It could also do this automatically with all the windows from the same/single app. It doesn't seem like it's impossible, and it could potentially be a lot more flexible than Windows MDI while still keeping the good points of it.

The closest thing I've seen to this is the multiple-windows-in-one-frame feature of PWM. But it's still quite different from Windows MDI.

There are no "infinitely large" objects., posted 10 Jun 2001 at 17:15 UTC by argent » (Master)

The menu bar may be "infinitely large", but you're never aiming for the menu bar, you're aiming for the menus (which are infinitely high but no wider than they would be anywhere else) then for the menu items.

The apple menu bar was fine when you had a 9" screen and one main application menu displayed at a time. It doesn't bother me much at all on my SE/30. But on a larger screen, unless you have mouse acceleration turned way up (and I hate mouse acceleration), I generally can't get from one side of the screen to the other without lifting my mouse.

I'll take context menus or menu bars over that any day.

What I'd really like to have is a way to tell the window manager that this window is a menu, and let the window manager put it wherever it needs to be: under the title bar, at the top of the screen, at the top of an MDI window, or under the mouse when you hit the menu button. Then it really DOES become a matter of "get a better window manager".

If the GNOME people spent more effort on stuff like that I'd be a lot happier putting up with the rest of the bloat that seems to be attached to GNOME apps.

About my cut & paste example..., posted 11 Jun 2001 at 16:56 UTC by Fyndo » (Journeyer)

For copy and paste, I'd agree it seems awkward to point your cursor to the top of the screen, however it seems almost equally awkward to point your mouse to the top of a window.
Agreed, however my point was that the fitts law analysis is somewhat invalid in a fitt's law analysis, because of the additional step of selecting which window is "active" by moving the mouse to that window. This means that you need to hit 2 targets in succession, the window, and the menu at the top, so the additional speed gained from having an "infinitely" large window is relatively small, compared to the total time. The analysis works with less common than cut & paste actions too.

So what can we do for Windows users?, posted 11 Jun 2001 at 21:28 UTC by Raphael » (Master)

Some of the replies (e.g., "Let the WM handle it", by carmstro) only help to prove the point that I mentioned in my previous comments: most of us know that we can handle many windows easily if we have a good window manager that offers virtual workspaces, and those who want a window-in-a-window MDI model can probably find a WM that offers that feature (under X). If there is no WM doing that, then Xnest can create a display-in-a-display and offer something similar. Not very useful, but it works...

But this does not solve the main problem: how can we improve the applications that are ported to Windows? In his comment "Education, not retardation", aaronl suggests to teach all users how to use better WMs. But this is not always possible. If the computer belongs to a company, school or university, the user may not have the Administrator rights that are often necessary in order to install the new WM. Most applications can be installed without special privileges, but this is not the case for shell extensions. Besides, a better WM will not change all native Windows applications that are based on the window-in-a-window MDI model. So even those who are able to - or allowed to - install a new WM will probably find that the ported application works differently from all other applications.

Wouldn't it be easier to provide the MDI features in the libraries (GTK+) and allow each application to use this option if the user selects it? That would solve the problems of the users who are limited by the default Windows WM, and it would offer more choice to those who may have a better WM but would prefer to have all applications (native and ported) behaving in a similar way.

Note: those who are interested more specifically in the user interface of the Gimp should read the following page: This is a response to a critique of the Gimp UI. The documenent is two years old, but many of the points are still valid. Make sure that your browser supports style sheets (CSS) in order to view the comments as intended.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page