In the comments to a previous post, we were asked about implementing tabs in the window manager. Calum pointed out that the HIG recommends against applications adding their own document-level tabs on the grounds that this is a job for the window manager. Yet the window manager has never risen to the challenge, and very many applications do in fact implement document-level tabs.
Implementing this will fall into three parts:
- there must be a way of identifying groups of windows which may be tabbed together (we might, for example, use WM_CLASS);
- there must be a display listing all tabs in the window border below the title (in a first revision, this could perhaps be done using the system menu);
- there must be a mechanism for unmapping all but the selected window, and, when appropriate, for reconfiguring the unmapped windows to match the mapped window (that is, when the mapped window is resized or moved).
There have been some volunteers willing to do the work in the past, but no word yet of working code. It should be a large piece of work, but not a monumentally huge one. Again, if anyone wants to help now, abundant assistance is available; this may be something the maintainers could work on, but not until the bug queue has been reduced a little more.
Photo © emdot, cc-by-nc-nd.
The way we do it in Compiz requires a bit of hacking around considering we are a compositing window manager.
Instead of unmapping the window, which has some side-effects – we remove the input shape of the frame window (if we are reparenting) and then don’t draw the window. This makes the window “invisible” to the user, but introduces some corner-bugs with applications that cannot deal well with having their input shape cleared.
A better idea would be to have some kind of spec in EWMH as an “input minimize”, however it might be difficult to have toolkits follow that.
The best solution (IMO) is to have an “InputUnmap” X Event that clients receive when their input is taken away but can continue to draw. If we just unmap the window, it’s pixmap will stay around and we can bind it to a texture, but the window will not update [because gdk thinks it’s minimized].
As for per-document window tabs, it would be interesting to see how that could be implemented. I don’t think it belongs in the scope of the window manager but if we could get some kind of EMWH spec for it, it would be great!
Hi,
Would be so nice to have metacity handling tabs for gimp images, epiphany windows, nautilus, etc.
Étienne
I am not sure if tabs would be great or used.
e.g. Epiphany:
* STRG-T -> new window, attach window to current window as tab
* STRG-N -> new window, do not attach window to current window
Developers would probably like to have application specific context menus for tabs (reload tab, undo close tab) or something like a small tab (+) to add new tabs. The goal would for sure be to have windows look like google chrome with the help of metacity :-) I guess thats not wise. I guess its better to have them handled by the application. Something like a standard gtk widget for this. Is it maybe wise to have the windowmanager overlay the app window with controls for consistent look and feel? Example app, wm adds close, minimize, … buttons:
_______________________________________
__|Tab | Tab | (+) |______
| |