Bugs and issues – Page 3 – …for the adult in you

Squib of the day: quit timeout

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.

Squib of the day: named colours

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.

Squib of the day: same button, different position

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.

Squib of the day: there’s an urgent thing going on

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.

Squib of the day: a removal van

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.

Bug of the day: maximise across windows

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.

Squib of the day: all (or some) menu options should have icons

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.

Squib of the day: talking to ourselves

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.

Squib of the day: Window paths

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.

Squib of the day: Tiling horizontally and vertically

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.