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):
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.
Stable release 2.26.0 hit the servers today. Not much is new and interesting therein, except for the translations, because most new hacking is going on in trunk (effectively the 2.27 branch).
What is it ?
What’s changed ?
Translations:
Amitakhya Phukan (as), Mikel González (ast), Ihar Hrachyshka (be@latin), Runa Bhattacharjee (bn_IN), David Planella (ca), Petr Kovar (cs), Ask Hjorth Larsen (da), Christian Kirbach (de), Jennie Petoumenou (el), David Lodge (en_GB), Jorge González (es), Mattias Põldaru (et), Iñaki Larrañaga Murgoitio (eu), Ilkka Tuohela (fi), Claude Paroz (fr), Ankit Patel (gu), Mark Krapivner (he), Rajesh Ranjan (hi), Gabor Kelemen (hu), Luca Ferretti (it), Takeshi AIHANA (ja), Changwoo Ryu (ko), Gintautas Miliauskas (lt), Sangeeta Kumari (mai), Sandeep Shedmake (mr), Wouter Bolsterlee (nl), Manoj Kumar Giri (or), Duarte Loreto (pt), Leonardo Ferreira Fontenelle (pt_BR), Adi Roiban (ro), Yuriy Penkin (ru), Daniel Nylander (sv), I. Felix (ta), Krishna Babu K (te), Theppitak Karoonboonyanan (th), Clytie Siddall (vi), Chao-Hsiung Liao (zh_HK), Chao-Hsiung Liao (zh_TW)
Where can I get it ?
Photo © Geoff Leeming, cc-by-nc. Thanks to Fin for choosing the picture.
Administrivia: I’ve nominated this blog in the Blogger’s Choice awards, more because it might bring in fresh readers and more insight than because I think it might win. Other GNOME blogs might consider whether they’d like to enter as well.
Some of the enhancements which have been suggested need some sort of hint to be set on windows. For example, the recent squib about a special style for warning windows could only work if warning windows were marked in some way, and at present they’re not. Similarly, drag and drop can only work better if the window manager is warned which clicks start a drag and which don’t. This too will need a new hint.
There are two ways this can be done. The simplest way is to use a hint whose name begins _METACITY; this doesn’t require us to talk to anyone. It’s sometimes one way of starting the process of adding a feature like this. Of course, it means that the feature’s unlikely ever to work with any other window manager.
The better and more extensible way is to make a new standard hint, one beginning _NET_WM. This means adding the hint to the Extended Window Manager Hints standard (the EWMH). Changing this standard means arguing it out on the wm-spec list. The maintainers would like not to be the only ones to raise new ideas on this list.
In either case, the toolkits (such as GTK) will then need to be updated to mark the relevant windows with the relevant hints, and finally the applications will probably need to be updated to use the new functionality in the toolkits. You can see, gentle reader, that enhancements like these are the source of more work than the average enhancement. They may nevertheless be worth the effort.
This entry exists mainly so that we can link to it when the issue comes up.
Photo © !!sahrizvi!! (back in Dubai) !!, cc-by-nc-nd.
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.
