Back in 2005, a Metacity crash when running certain SDL apps was reported in GNOME bug 169684.
This bug remains at “critical”, but there has been no new comment on it for five years. Nobody appears to be experiencing the same problem now.
Gentle reader, do you have any experience in SDL? Can you tell us whether the problem is still present?
Photo © Ingy the Wingy, cc-by-nd.
GNOME bug 616743 includes a patch which, if you have stereo speakers, will make the system bell move horizontally depending on which window it happened in. For example, if you’re editing a file in a terminal on the left of the screen, and the terminal bleeps, the sound will come from the left. If your mutt terminal is on the right of the screen, you will hear a bleep on the right when you receive new mail.
Sounds other than the system bell won’t be affected by this change. For example, music played by a music player will not be affected by the position of the window.
(The patch also appears to set the vertical position of the system bell according to the y-coordinate of the window. Your chronicler is having difficulty imagining the sound system where this would be distinguishable, but perhaps is not experienced enough in these matters.)
We are rarely minded to accept enhancement patches, since every new line of code is a line of code we have to maintain for ever. However, this one isn’t complicated, and appears to have a positively useful result.
What are your thoughts on the matter, gentle reader?
Photo © whisperwolf, cc-by-nc.
As we mentioned the other day, there are some situations where Metacity’s ability to mark a window as running as root is unhelpful. One of these is during installation: this naturally runs as root, but it baffles new users to be told “Install (as superuser)“.
For this reason , GNOME bug 605137 requests a hint which can be added to a window to suppress this message.
Thomas has implemented this as the hint
_METACITY_HIDE_USERNAME, and there is also a test case.
This patch may also be of use to other distributions, assuming we keep the “(as superuser)” ability at all– see GNOME bug 609431. It may not necessarily go into the master branch, unless it would be useful to other people. If it doesn’t, perhaps it can be a distro patch.
Photo © Sharyn Morrow, cc-by-nc-nd.
Metacity’s window menu is less than cluttered; there’s room for a fair amount of extra options in there. One that was recently suggested is an option to take a screenshot of the current window. However, that can be done already using keybindings. What about more adventurous use of the menus?
GNOME bug 472370 makes the reasonable suggestion that Metacity should contain an IMAP client. It would be possible to read your GMail inbox right from the system menu of any window. After all, Zawinski’s law points out that programs which cannot read email are overtaken by programs that can, and if Compiz contains an email client, your chronicler has yet to hear of it.
This appears to be a perfectly sensible idea, and our prototype is demonstrated in this post. It will be included in the next unstable version. After we iron all the bugs out of this, we might deal with focus fixes if we have the time.
GNOME bug 105188 suggests that prelighting– lighting up buttons when you hover the mouse over them to confirm that it’s okay to press them– should fade in from the non-prelit state. This was originally said to require a change to the theme format, but in fact I can’t see that it does: any theme which defines a prelit state for buttons can fade gently from one to the other.
Perhaps there should be an option to turn this on, or perhaps it should just be the default way to behave and stay there.
Photo © quapan, cc-by-nc.
Someone who believed the system menu should be shorter raised GNOME bug 126674. The basic idea is that the options in the system menu which move the window to adjacent workspaces and to workspaces given their number are unwieldy and complicated.
Since these options all move windows, and since there is an existing manual move mode on the menu, the reporter suggests removing the workspace entries entirely from the menu and replacing them with some keypresses in manual move mode. For example:
- switching to manual move mode and then pressing F5 could move the window to workspace 5;
- switching to manual move mode and pressing Ctrl+Right could move it one workspace to the right
- and so on.
It would undoubtedly remove some complication in the user interface, and free up some space for useful other options (such as “screenshot this window”), but perhaps at the cost of making common operations prohibitively difficult to find. The bug suggests that a popup window like the Alt+Tab window might give instructions about example keypresses. This would also make moving windows to another workspace with the mouse more difficult, but perhaps people should be doing that with the pager anyway.
Photo © Glenn Loos-Austin, cc-by-sa; thanks to Katie Sutton for choosing it.
When you click the close button on a window, the window can have a hint on it which tells the window manager not to close it immediately. Instead, it should ask the window to close itself, and if the window doesn’t respond within a certain amount of time, it should put up a dialogue box which asks whether to kill the process which owns the window.
At present, this amount of time is fixed in Metacity to 2.25 seconds.
GNOME bug 121934 suggests that this timeout could be different in some cases:
- If the window usually takes “a long time to exit”. This would require window matching.
- Generally, because 2.25 seconds is too short a time to wait. On the other hand, if it was much longer, the user might have forgotten closing the window and would be surprised by the “force quit” dialogue.
- When the system is under heavy load, so the program is less likely to be able to respond.
Photo © rwangsa, cc-by-nc-nd.
GNOME bug 121866 would like a way to set drawing colours according to palette entries in bitmap images in the same theme, as well as giving literal RGB values or giving a reference to a GTK colour. It is suggested by the reporter that this could be done with the XPM format, which allows colours– or rather, entries in the palette– to be named instead of specified: foreground, for example.
This is quite a vague requirement. Because this requires a change to the theme format, it must be committed first on a branch. However, using bitmaps in themes at all is somewhat deprecated.
A useful variation on this idea would be to allow a set of colours to be undefined within a theme, which could be done by extending v2’s support for colour constants, and then allowing other sub-themes to specify only the missing colours. Or perhaps the user could choose the colours for themselves as parameters to the theme; this part we could even do already with no change to the theme format, by adding a new GConf key which allowed redefinition of colour constants in the current theme. You can imagine a standard utility which would read the theme file and give the user colour pickers for each constant, then set the values in GConf.
This would then bring us back to the original problem and might require us to be able to change a specific colour in bitmaps as appropriate; alternatively, we could just say it was one more reason why bitmaps in themes are a bad idea.
Photo © Bernat Casero, cc-by-nc-nd.
GNOME bug 120705 points out that Metacity doesn’t allow users to put a button into the titlebar twice– so, for example, you can’t have a close button on the left and also on the right hand side.
There is no particular reason for this: it was merely an artifact of the original code which has been preserved. However, not allowing a button to repeat has a possibly useful side-effect of providing an upper bound on the number of buttons which can appear.
Is there anyone out there who would actually want to put a button on the titlebar more than once?
Photo © Kup Kup Land, cc-by-nc-sa.
When a window gets the demands attention hint (_NET_WM_STATE_DEMANDS_ATTENTION) or the urgency flag, the pager flashes the window’s entry on the taskbar. Other pagers such as AWN may bounce the window’s icon in their dock. However, the window itself doesn’t change at all. To remedy, this , GNOME bug 120406 suggests that the frame, or the titlebar, of a window which demands attention should flash as well.
One problem with this is that a window which demands attention necessarily isn’t on top, so is likely to be at least partly obscured. On the other hand, someone suggests that the existing visual-bell mechanism could be reused here instead.
Photo © juliebee, cc-by-nc-nd.