GNOME applications currently follow two different metaphors regarding the relationship between documents and windows. Some applications use a Single Document Interface (SDI) as recommended by the HIG, i.e. one window per document, as for example evince, nautilus, eog, and inkscape. The first two also obey spatial behavior, i.e. they remember window position and size per document resp. folder. Other applications use a Multiple Document Interface (MDI), i.e. one window by default and one tab per document, examples: gedit, epiphany, firefox, devhelp. This week I had the idea of a third way that might work well for most applications.
SDI is very simple to use and quite convenient when combined with spatial behavior as you can arrange your document windows how you like it and you’ll see your documents exactly the same each time you open them. The main disadvantage of SDI is that you end up with many windows, one for each open web page, folder, conversation, text file, and more. The window list applet and the Alt+Tab window switcher don’t scale well, you spend a lot of time finding your window when you have several dozens of windows open.
That’s why some applications use MDI. You’re able to manage your documents or web pages on two levels, that means the window list applet and Alt+Tab are a lot more useful again. A disadvantage is that the configuration of your windows vanishes when you close the window. This may mean that you keep your windows open relatively long, also across logout/login, so that you don’t have to arrange your windows that often. You end up with quite a lot of open windows, again, using more memory and taking time when restoring your session.
My idea now tries to combine the main advantages of the two approaches by making windows first-class objects. So instead of treating windows and documents as the same or forgetting about a window as soon as it’s been closed, treat windows as separate objects. I want you to care about your windows, give each of your window a name, an icon, maybe even a special color for the window frame. Windows should be persistent: if you close a window, its name, icon, position, size, and content should be kept. You can open this window again by using the name and icon you’ve chosen. Creating and destroying – in contrast to opening and closing – a window should be a conscious action, not something that happens as a side-effect of something else; there will be exceptions, of course.
A more concrete proposal follows: Replace the window list applet by something like the dock in Mac OS X with the big difference that it’s about windows instead of applications. The main part is a persistent list of icons of open and closed windows; the windows are stored as desktop files. If you click on an icon and the window isn’t open yet, it will be opened, i.e. like a launcher but you get your documents back. If the window is already open, it just activates the window. To the right of this icon list is a list of currently open non-persistent windows, just like the current window list applet.
Metacity should also have knowledge of the persistent windows and set the visible window title and icon according to the user’s configuration. Applications should use tabbed MDI as basis and add support for restoring windows by name – similar to the session restore feature already implemented in many applications.
Does this make sense or am I missing something substantial? I’ve implemented a proof of concept applet in Vala and patched epiphany to work as described, will import it into some repository later, if there is interest.
Sound nice.
Could you please provide some screenshots so one can better imagine how this should work in real?
thx
I generally think this is a good idea. And I think this fits well with the notion of taking away the application-centric desktop. Meaning that the functionalities needed for a particular kind of document will open together with that particular document. This probably won’t be possible in all cases, but it could be done in most cases, I think.
Another solution would be to implement tabbing at the window manager level. Work is going on in that area here and there, but personally, I’m not such a big fan. I think I just prefer MDI…
Metacity lets you tab through windows created by the same application, actually. Can’t remember the keybinding — on KDE now — but you can get pretty much the same behaviour you get under OS X.
Sadly, one of the application that does not behave well with this is, surprisingly, GNOME Terminal. Another problem is that Compiz does not implement it yet.
I think this is ridiculous, in my usage patterns I do not expect certain documents to appear at a fixed place. And I certainly wouldn’t take the time to create “named” windows. IMHO.
I’d be sceptical of the value of forcing users to manually color and name things. Anything. It’s a pain in the ass, and not relevent to the task at hand.
And I’d be less focused on windows and more focused on the documents or applications themselves. There should be an obvious 1:1 mapping between them. A single document on the desktop results in a single window.
Also, there are some applications which are not served by being launchable without a document context. Gedit is one of these. There is no reason to open gedit. There are only reasons to create new documents and open them or open existing documents. I’d try to clear this up.
That said, you’d end up with a set of icons in your launcher which corresponded to actions: new document X, open document Y.
Applications that are not document centric do sort of stand out, though.
It would be a neat thing to be able to group windows/application by task.
Today I switch between different accounts for different tasks.
One for coding, one for administrative work and one for just plain casual use (web/music/movies). Needles to say.. there is quite an overlap in applications (web-browser, IM, irc and general desktop apps). If I could switch applications depending on the task I was performing it would remove my need for seperate accounts and free up a lot of memmory.
And no, seperate workspaces is not quite cutting it here.. I use many workspaces for all of these “tasks”.
Interesting proposal. There some interesting idea, but it sparked an
idea, and I come with another proposal.
SDI and MDI are both broken. MDI with tabs is broken as I may want to
work with two documents, viewing both at the same time. For instance I
may be filling a form in Firefox, from info on a second webpage, and I
would like to display both side to side (I have a very wide screen). SDI
is broken as it clutters windows switching. If I am working with the
Gimp, with a large amount of windows open, switching from on to another
is not easy, as I have maximize all of them, to see the whole picture.
I propose a tab-oriented MID from which I could rip off tabs. Gnome
terminal does this. It also as the brilliant feature that I can drag a tab
from one Gnome terminal to another. Moreover I want to be able to drag
back a tab in a window. I also would like to be able to rearrange tab so
that they pave the window. For instance I would like to start from a
situation as seen on http://www.gael-varoquaux.info/tabs/start.png , grab
a tab by its label, and drag it to the side of the window, as can be seen
on http://www.gael-varoquaux.info/tabs/move_to_side.png (the cursor has
not been captured by the screenshot), to end up in a situation like
http://www.gael-varoquaux.info/tabs/split.png , and to be able to move be
to initial situation by dragging the tab header to next to the other tab
headers, as can be seen on
http://www.gael-varoquaux.info/tabs/move_to_tab.png .
This behavior is actually implemented by Mayavi2, if you want to try it,
instruction for instal are on
https://svn.enthought.com/enthought/wiki/Install .
If you like this idea, please repost it on your blog, it will have more
impact like this, and it get go around in the Gnome community. I’d really
love to see this implemented.
Cheers.
This concept of “closing a window and it becomes a desktop icon”. Ummm. Isn’t that iconification, which has been around for decades? And rather than “a specific coloured border” or whatever, isn’t a thumbnail of the contents more useful? So you’re basically talking about using the desktop itself as a window list, with open documents shown as thumbnails of their contents. Sort of like having an always-on Exposé.
– Chris
@jospoortvliet: A tabbed window manager doesn’t solve the issue that the window arrangements are not persistent, I don’t want to manually group windows all the time. You could probably implement something similar to my suggestion on top of a tabbed window manager.
@Michel: I don’t want the same behavior as in OS X, there it’s all application centric and that’s not suitable if you use multiple windows of the same application for different purposes – I’ve never used OS X, so I don’t really know the dock.
@Richard: It’s not about single documents, more about windows that you’d reuse for many documents (usually for one task).
@Jerome: The naming should of course be optional, you can always just use the default window title. I hope you didn’t expect a popup with a text entry every time you open a new window. The intension is that you can set a name if you want to use the window regularly. The 1:1 mapping between documents and windows results in way too many windows for many people. I don’t want to open empty gedit windows but I may want to open a gedit window with 5 documents I often edit together and so it makes sense in my opinion to be able to create a launcher (optionally with custom name and icon) for the combination of the 5 documents.
@Gaël: These features – as for example also found in Eclipse – make certainly sense for many applications, it would be very nice if e.g. gedit had this. The two ideas are not in conflict and can be implemented independently, though.
@Chris: I’m not talking about iconification. The window should have a persistent icon that stays there when you really close the window, not just hide/minimize it, it also remains at the same place after logout and login (independent of session restore). The colored border would be a window border, not only an icon border, this might help identifying the right icon faster than with small thumbnails. I also didn’t suggest to use the desktop background as a window list, it should still be in a panel applet or dock-like window.
Just a small clarification here. Epiphany supports tabs because it’s a basic necessity in the web browsing experience and the window manager doesn’t solve the problem for us.
However you’re not forced to use tabbed browsing in Epiphany, and if you don’t, you’ll notice it behaves very much as an SDI-application.
@reinouts:
Would be awesome if epiphany supported detaching tabs and attaching them to a different window. I currently have 10 epiphany windows open with over 10 tabs in each and it’s a maintenance nightmare because to move a tab to a different epiphany window (where each window is meant for a different topic – gnome bugs in this window as tabs, gentoo bugs in that window as tabs, etc) after it has been opened in the wrong one due to “open in new tab” usage.
@Gaël: Is this wxAUI that you are describing? I see the deps list wxPython-2.6, not 2.8 where it was added to wx proper. I suppose it’s using an external AUI if it’s only 2.6 that’s made available?
In general, I don’t see what value does this idea provide that a proper detachable tabs idea doesn’t – like gnome-terminal provides.
@Mart: see this bug: http://bugzilla.gnome.org/show_bug.cgi?id=400363
@Michel: The shortcut for switching between windows in an application is the CUE standard, Alt+F6.
@Mart: In a way yes. Mayavi2 does not rely on it in its current version, but once we move to traits3, we will indeed be using wxAUI. In the meanwhile I think we are using some home-made code (it is buried in traits, and I don’t have the courage to look).
The value this adds to gnome-terminal like behavior is the ability to re-attach tabs, and the ability to have a split-screen (a bit like mc, or emacs, vim…). It is also very versatile, so we we are constraining the user.