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.
One of the forks of Metacity is known as Mutter, because it’s Metacity with Clutter support. It’s used by the forthcoming gnome-shell project.
In a recent email to d-d-l, Owen Taylor gave two goals for the 2.28 release:
- That Mutter should be developed using the GNOME infrastructure; and
- That users will be able to choose between gnome-shell and ordinary Metacity.
Some possible ways of doing these were suggested:
- Merge Mutter and Metacity. Have Mutter as a separate compositor within Metacity. Alternatively, as Colin Walters suggested, make Mutter a separate branch within Metacity’s DVCS.
- Import Mutter as a separate window manager. Remove all the parts in Mutter which are left over from Metacity and don’t work towards Mutter’s goals. Metacity remains for people who don’t want to run gnome-shell. Eventually it dies off.
One advantage of making gnome-shell play nicely with a standard (possibly Mutterised) Metacity is that it would still be possible to switch to other window managers: a great deal of ink was spilt in the discussion over whether users would mind switching away from Compiz, whether the Compiz developers would mind, and whether Compiz was the de facto standard window manager these days. However, Owen says that gnome-shell requires tighter coupling with the window manager than is usual, and that this isn’t really an option.
The discussion continues…
Photo © Alexander Drachmann, cc-by-sa.
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.
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.