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.
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.
Two rather similar squibs today.
GNOME bug 96348 calls for an animation to be shown when restoring (unminimising) a window, as we already do when minimising. I can’t see any problem with this idea.
GNOME bug 97288, however, would like all new windows to have the opportunity to come from somewhere. If you open a document from the file manager, for example, the window should appear to zoom out of the icon. Presumably this would involve modifying the startup notification protocol to pass in a pair of (x, y) coordinates. This would need some changes to nautilus and friends as well as to Metacity, so it seems non-trivial.
However, even if these coordinates were missing, we still know the ID of the window which launched the new window, so we could assume it came from the centre of its launcher. Something similar could also be done with transient windows.
Photo © lant-70, cc-by-nc-nd.
In GNOME bug 94111, Havoc points out that some of the macros we use for checking certain features of windows are incorrect. Fields with names like has_foo_func denote whether the window gives us permission to foo it. Macros with names like ALLOWS_foo take these into consideration and also whether the operation is possible right now (for example, you can maximise a window only if it allows maximisation in general, and also if it’s not currently maximised).
The bug requires checking these macros have correct names, and making sure they do what they’re intended to do.
This whole business does make me wonder why we’re using macros for this sort of thing, anyway. Given a modern compiler, do macros win us anything that inline functions don’t, besides extra difficulty in debugging and readability?
Photo © Thristian, cc-by-sa.
When GNOME bug 86590 was born, it was a request to make workspaces switch instantaneously when you panned around them using the workspace switcher with ctrl+alt+arrow.
Then that was fixed, and someone else complained that it was too slow, and inconsistent with the alt+tab popup, which doesn’t switch until you let go of alt. They asked for it to be reverted. Someone else suggested a compromise: if the user pauses while moving through workspaces, flip to that workspace without removing the pager.
Of course, then we’d have to consider whether we should do that with alt+tab, too. It’s possible that the two cases are different enough that there’s no good analogy here, though: workspaces can be named, for example. It’s possible as well that they’d become different enough for there to be no good analogy here if we had thumbnails of the workspaces instead of the icon-based boxes we have now.
So the options now are:
- Switch when they let go of the keys, as we used to.
- Switch after a delay, as suggested above.
- Maybe it’s fast enough these days and nobody cares any more.
- We could keep all the windows on all the workspaces mapped all the time, like Compiz does, which would make things a lot faster anyway, and would reduce to the previous case.
Photo © Matsatsinis Fragiskos, cc-by-nc-nd.
At present all lines are drawn at the same thickness. However, some people such as partially-sighted users require particularly thick lines . GNOME bug 86040 suggests that the line format be extended to give the width as a fraction of the current icon height.
Since this is a change to the format, it must appear first on a branch. This bug actually predates v2, but wasn’t included in that version because it wasn’t marked as blocking the v2 tracker bug.
If this would still be useful to anyone, it could certainly still go into v3 of the theme format.
This bug is perhaps the first place where the use of SVG was suggested as a workaround for having to add new features. Elsewhere, someone also suggests a novel idea of allowing themes to ship TrueType fonts which contain unusual glyphs, in order to have access to another well-defined vector graphics language. Of course, this would be subsumed if we decided to use SVG.
Photo © Callistobreeze, cc-by-nc-sa.
In GNOME bug 80984 (closely related to GNOME bug 76672), someone is asking for the window manager to help out with drag-and-drop. The problem is that a drag-and-drop operation should not raise the window it begins in, because raising that window could obscure the window you’re planning to drop the object into.
This is a reasonable and important request. It is, however, not at all simple. Metacity is the program which decides whether to raise the window, and there is currently no way for Metacity to know you’re about to start a drag-and-drop operation.
One rather crappy workaround is to tell it by holding down Super or AltGr. This works, but it’s not elegant. The system should be able to know.
This is not what raise_on_click does. Please forget about raise_on_click. It won’t solve your problem.
The correct answer is fixing this in the EWMH. Luboš had an idea about this back in 2004 called _NET_WM_TAKE_ACTIVITY, and Elijah improved on this later with a more complicated idea called _NET_WM_MOUSE_ACTION. Getting this into Metacity is GNOME bug 152952. Whatever happens, it’s going to need changes to GTK and to various applications, particularly including Nautilus (the file manager).
Far more of a detailed writeup, including feedback from some of the people involved, is found in this entry. Your chronicler believes that implementing this is worth the fairly considerable effort to fix.
Photo © wili-hybrid, cc-by.