Window managers with workspaces vs. Windows MDI

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

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?

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 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.

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.

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?

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.

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.

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.

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.

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.

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.

Many user interface people have criticized microsoft for the window-in- window MDI, including Tog (see http://www.asktog.com/readerMail/2000- 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.

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.

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

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.

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

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.

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.

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.

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.

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: http://tigert.gimp.org/gimp/ui-critique/. 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.