Thanks to Elijah Newren and Thomas Thurman for improvements in this version.
Contrary to rumour, this release does not add tabbing to everything.
- Display theme name in title bar of theme viewer (Thomas) (GNOME bug 430198)
- Allow toggling of non-compositor effects (Thomas) (GNOME bug 92867)
- Add some extra null checks (Thomas) (GNOME bug 422242)
- Check for double-freeing at the time of workspace freeing (Elijah) (GNOME bug 361804)
- Don’t generate log messages unless we’re logging (Thomas)
- Two windows which don’t belong to any application can’t be considered to belong to the same application (Thomas)
- Various tidyings (Thomas)
Translations
Yavor Doganov (bg), Gabor Kelemen (hu), Kjartan Maraas (nb), Matej Urbančič (sl), Daniel Nylander (sv), Theppitak Karoonboonyanan (th)
The irony here is that metacity is the one GNOME component that *would* benefit a lot from supporting tabs. See for instance http://bugzilla.gnome.org/show_bug.cgi?id=355438. If metacity would support window grouping with tabs, we’d get rid of tabs in Epiphany in an instant– there are too much usability problems with it to mention.
That’s an interesting point. I wonder whether it might be like the way MS Windows writes a number next to the name of a group, and only shows the one entry for it, if you have more than a few windows open.
I’m not sure what you mean; doesn’t Windows only use that notation in the task bar? Representation in the window list is an issue separate from visually grouping windows on the desktop, in my opinion. Besides, the window list applet already supports grouping in a similar manner.
In any case, I don’t see why we would limit window groups to windows of any single application. If technically feasible, a user should be able to group an Epiphany webpage, an Abiword document, and an Empathy conversation, if they all happen to be related to the project (s)he is currently working on. (Of course, by default a new tab|window should be added to the focused window when the user selects “New Tab” or whatever.)