It’s suggested in GNOME bug 82567 that Metacity could allow a left-click on the titlebar to launch a menu which allowed the user to navigate to the parent, grandparent, or further ancestor of the window. This would only make sense where the window could represent a container which itself was contained in some other container hierarchically (which amounts to the file manager, pretty much).
This would require a new window hint in order to work. It would replicate behaviour that is generally the province of toolbars and appears to have WONTFIX written all over it.
This is similar to a more useful and general recent suggestion that windows should be able to add a draggable icon in the titlebar, as is done on OS X. Your chronicler would like to see this done, but is aware that the obstacles between there and here are formidable.
Photo of Jackson the dog © ItsGreg, cc-by-nd.
For the record, these both sound like “please act like the Mac” bugs. As I understand it, in OS X there is an API that says “this window represents this path”. Once a window is associated with a path, two things happen: firstly, the file’s icon appears in the titlebar next to the title (which is usually the file-name for such document-based windows), and secondly if you hold down the waffle key and press the title or icon with mouse-button one then a pop-up menu appears, with an item for the path itself and for each directory in the hierarchy up to the root.
There are some other cultural differences to bear in mind, also: since the Macintosh Finder is generally spatial, Finder windows have no in-window navigation controls, and if you have already closed the parent or grandparent windows of a particular directory, the titlebar popup is a really handy way to get them back. Also, the titlebar popup opens a new window for the path in question (or brings that window to the foreground) rather than replacing the current contents of that window.
Another thing I should mention: this feature isn’t just restricted to the file-manager – normally every window that represents a document has the document’s icon in the title-bar, which makes it really easy to open the directory containing the current document – very useful if you keep all the files for a particular project together.
I would expect that the simplest interface for such a feature would be to support a “window VFS path” hint. Then you can interrogate the GNOME VFS library to find the associated icon and path-to-root, and tell it to launch items selected from the popup menu.
Of course, that’s rather GNOME-specific, which might prevent it being accepted by the EWMH spec. A more low-level system (not sure if this is possible with window hints) might be to support a hint that contains a list of (icon, text, callback) tuples – the icon in the first entry would be used as the window icon, the entire list would be used to generate the popup menu, and the callback would be called when the relevant item was selected. The GNOME and KDE standard libraries could have a utility function that accepted a window and a VFS path and automatically set up the hint. A further advantage of this system is that it could be overridden by applications – for example, Macintosh web-browsers often display the current site’s favicon in the titlebar rather than the generic “HTML document” icon, and their popup-lists go to the root of the website rather than showing the path to the browser’s disk-cache.
There’s another related feature you haven’t mentioned, but which affects this squib: the Macintosh has another API call that says “this document in this window does/does not contain unsaved changes”. When a window is marked as containing unsaved changes, its icon is drawn in a disabled state and is not draggable (the logic being that the file you would be dragging does not represent the current state of the document).
To summarise: I agree that this makes more sense in the Macintosh tradition of “one window == one file on disk”, but I think it would be a useful and handy addition to the GNOME desktop nevertheless.