In GNOME bug 120204, someone suggests being able to pick up all the windows of an application and move them to another workspace, and also to minimise them, close them, etc. This could be done by holding down some kind of modifier while the function is being selected; this may violate the principle of least astonishment, in case someone made all their windows disappear without meaning to, merely by holding down Shift or whatever.
On the other hand, someone (who apparently used Vietnamese localisation) suggested using dialogues, with this as a possible UI:
I think this is perhaps over-baroque. I’m not sure this feature is useful enough for the downsides of either method to be worthwhile.
Photo © Jay Gooby, cc-by.
GNOME bug 119187 requests a new super-maximised window state where a window can be maximised across several Xinerama screens simultaneously, and a keybinding to toggle this state. Apparently you can do this in Windows XP by shift-clicking on the maximise button.
Since this is a new window state, it would require a change to the EWMH, which makes it nontrivial.
Would it be particularly useful to anyone out there?
Photo © skenme, cc-by.
Currently, only some of the options on the window menu have icons beside them. GNOME bug 118405 suggests that all of them should, or at least that any option should have an icon whose inverse already has an icon, for consistency. Whether the icons should change according to the theme is also discussed.
Photo © robin-root, cc-by-sa.
Metacity knows when a program is loaded, but hasn’t yet started, by using the startup notification specification. In GNOME bug 114384, the suggestion is raised that when Metacity opens a new program (say, from a keybinding) it should also tell itself that the program is loading in the same way.
This seems entirely reasonable.
Photo © Janet McKnight, cc-by.
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.
In GNOME bug 85523, the idea is raised of having an operation to tile all windows horizontally or vertically. (This may be similar to a feature found in some versions of Windows.)
The original idea was to put the option on the window menu, which Havoc vetoed because the window menu is already rather full, and because this is an operation over the desktop as a whole rather than on one window.
It was further suggested that this could become a keybinding, or an option on the menu the user sees when they right-click on the desktop (which would make it not a Metacity issue).
Since this could easily be fixed with a script, your chronicler would have no qualms against closing it with WONTFIX. However, if it should really be something Nautilus does, then this is a Nautilus problem and not a Metacity one.
Photo © Chris Campbell, cc-by-nc.
GNOME bug 107012 brings up the perennial question of SVG support in themes, otherwise known as Vectacity. We’ve already covered this in a few places, but I think it may be worth mentioning here the two main reasons SVG-based themes is a good thing (there may be any number of other reasons they’re a bad thing, as well):
- SVG is now a clear standard for vector graphics. So theme artists will be able to reuse their existing knowledge about SVG when coming to design Metacity themes.
- It means we can remove large amounts of code from Metacity and use whatever SVG library we end up depending on instead. (There is a heavy presumption that this library will be GNOME’s own librsvg.) Having less code around is generally a positive thing.
However, stretching SVG to meet our needs, or indeed stretching librsvg to meet our needs, rather negates the second benefit: it’s possible that including CSS will let us do what we need, but it’s also possible that librsvg is not clever enough to let this happen without so much coaxing on our side that we may as well have written an entire SVG library of our own, which is something we’d like to avoid.
If Vectacity ever becomes a reality, it certainly needs to be possible to convert a v1 or v2 theme to Vectacity automatically. This is partly for the theme artists’ benefit, but also because it means if a Vectacity-enabled Metacity finds itself having to load a v1 or v2 theme, it can do the conversion by spawning a separate program rather than having to keep the legacy code for reading v1 and v2 themes lying around, which again negates the second benefit.
Forthcoming versions of SVG are specifically considering use by window managers, but we may have to wait a while for them to get into a usable format. It may be best to WONTFIX this one, at least until v4. On the other hand, the two benefits given are indeed important benefits, and I’d like to see it happen sooner.
Photo © freebird (bobinson|ബോബിന്സണ്), cc-by-nc-sa.
Did you know that the xrandr extension uses a 16-bit quantity to store the millimetre width of the screen? That gives a maximum screen width under X of about 65½ metres. Granted, this is about three times wider than a good-sized cinema screen, but it’s certainly a limit to try for. Imagine, you could get the whole of Hamlet in your AbiWord window at the same time.
Anyway, GNOME bug 106239 suggests that on “giant” displays (the meaning of “giant” left ambiguous), newly-created windows should appear near the pointer. If we grant that this is a good idea, should we also do this on small displays? If not, where’s the cut-off?
(Clue: introducing a GConf key is going to be an unpopular move.)
Photo © naan, cc-by.
GNOME bug 102548 suggests that warning dialogues should have a special frame style, and it’s suggested that this could look like safety tape wrapped around the edge.
This is not unlike the special frame style suggested here for root windows. However, while there’s already a way for the window manager to tell whether a window belongs to the superuser, there’s currently no way to tell whether a window is a warning, so this would need a change made to the EWMH and then need all the toolkits fixing to use it. It’s thus rather nontrivial, although it may still be worth it if it helps users.
Because this requires a change to the theme format, it must be committed first on a branch.
I am seriously entertaining the idea of doing away with the window and frame_style_set tags in v3 of the format, and just using tags on frame styles such as maximized, shaded, focused, unfocused, root, warning, modal, and so on, with some well-defined and intuitive rule about how to break ties:
<frame_style geometry="foo" tags="border focused maximized">
<piece position="title"> ...
Photo © Robin Gallagher, cc-by.
In GNOME bug 140362, someone requests the ability to maximise one side of a window to the edge of the screen by double-clicking the frame. Thomas provides a patch, there is some discussion, and the reporter realises that Metacity already does most of what is wanted through the ability to resize in one direction only when Shift is held down.
Your chronicler believes that this bug may be fairly closed since the reporter feels happy about the existing system. If anyone would like to make a case for double-clicking the frame having this effect, now’s your time to speak out.
Photo © brewbooks, cc-by-nc-sa.