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

Bug of the day: hiding “(as superuser)”

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.

Bug of the day

There are several hundred bugs still open in the Metacity bug tracker. Over a hundred of these are enhancement requests.

During the first quarter of last year, this blog ran a daily “bug of the day” or “squib of the day” feature, where suggested enhancements would be discussed. Every so often, there’d be a roundup post where the fate of the bugs of the previous few weeks was revisited. The idea was that decisions could be made in the open rather than behind closed doors.

That was all very well, and it got the community more involved in discussing new features. However, there were two main problems:

Enhancement bugs are probably the least important kind of bug, and yet they’re the most interesting to write about. So this plan focused people’s attention on the least important things.
There’s only a few people who are willing to hack on Metacity, and they only have a certain amount of time available to do it. This plan meant that more time was spent writing blog posts than writing patches.

It might be useful to resurrect this feature, but not unless these two issues were addressed. Perhaps we should extend it to covering all kinds of bugs in order of priority, and instead of having daily posts have a strict rule that nothing new could be posted until the previous bug had been dealt with. Perhaps your chronicler should also delegate writing the posts, if some willing amanuensis could be found.

Photo © wiccked, cc-by-nc-nd.

“(as superuser)” considered harmful

About a year ago, we considered the idea of showing the name of the user running a program in the titlebar, as suggested by GNOME bug 549389. So if you were running Epiphany as user fred, and you yourself were not user fred, you would see “(as fred)” in the titlebar. More commonly, if you were running Nautilus as root, you would see “(as superuser)” in the titlebar.

This eventually made its way to being commited to the master branch.

Various problems have since arisen:

Several people still say that it should say “as root” instead of “as superuser”. The wording was chosen for fear that “root” was techspeak, but apparently “superuser” is as well.
gvim is somehow able to fool the user detection and displays “as superuser” even when it’s not. Your chronicler suspects the EWMH properties are misapplied, but has not yet investigated. This is Debian bug 549290, Gentoo bug 292517, and GNOME bug 603240.
Colin Watson has asked in GNOME bug 605137 for a way to suppress the message on particular windows, because the Ubuntu installer runs as root under Metacity, and the user doesn’t need to be worried about the “as superuser” part. This is certainly something we can do, assuming we keep this feature at all.
Launchpad bug 519035 (which is GNOME bug 609431) says that any attempt to mark the titles of windows owned by root is “techspeak and ineffectual”.

We could:

keep things as they are
rename “(as superuser)” to “(as root)”
remove all visual indication that a window is running as root, but leave it in for running as other unexpected users
remove the patch entirely
replace the patch entirely with a way for themes to specify a titlebar style for windows running as root; this was GNOME bug 505157 and wouldn’t be very difficult with CSS themes (“frame[is-root] > titlebar { background-color: blue; }“).

Gentle reader, your opinions are welcome.

Photo © Esparta, cc-by.

Alt-Tab over all workspaces

At the moment, when you press alt-Tab, you cycle through a list of windows on the current workspace. People use workspaces in many ways, though; some people keep only one application maximised on each workspace. Very many people have asked for the ability to alt-Tab between windows on all workspaces, not just the current one.

There have been many bugs raised about this matter. One approach, taken in GNOME bug 577699 by Alexander Larsson, is to add a new keybinding called switch_windows_all, which can then be re-bound to alt-Tab. This is certainly a possibility, but adds a new keybinding and a new GConf setting. It is apparently how Compiz solves the problem.

A different approach was suggested six years ago by Havoc in GNOME bug 143511. The window list in the panel has the option of toggling between a list of all windows and only the windows on the current workspace. It is contrary to the principle of least astonishment if the windows listed in the alt-Tab display are not the same as those listed in the panel.

Therefore, the window manager should detect this setting in the window panel list and behave accordingly. This could be done simply by reading the setting out of GConf. A more portable way would be to have a new EWMH hint on the root window; however, this was raised on the wm-spec-list in 2007 and was not well received. Generalising GNOME’s panel to all environments may be tricky.

Again, anyone wishing to work on this will have abundant help available; otherwise we will get to it when the bug queue is reduced a little. GNOME bug 143511 is the one to follow.

Photo © Scott Ableman, cc-by-nd.

Snap

There has been some discussion on the last post about implementing functionality similar to Microsoft’s “Aero Snap”. Your chronicler has never used Windows 7, but the idea is demonstrated in this video. It appears to mean that:

when a window is dragged to the left or right of the screen, it is vertically maximised, and resized horizontally to half the screen width;
when a window is dragged to the top of the screen, it is maximised;
there are hints elsewhere that dragging to a corner minimises, but this is unconfirmed at present.

There are apparently several people who would like this implemented on the free desktop.

One option is to do it with an external tool. This is the route taken by this tutorial by gotsanity. It’s a simple matter of monitoring the root window for configure events; the link goes to a program which will demonstrate the general principle. Making that program into a daemon which will solve this problem is only a matter of adding code to detect a window crossing screen borders, and some kind of payload for when one does.

The advantages of this approach are:

that it will work with any window manager, and
that we have previously said that almost anything which can be implemented externally should be, to preserve the lightweight nature of Metacity.

The disadvantages, however, are:

the need to keep a separate daemon running; this is a good deal more of a long-term problem than launching one-shot processes on a keystroke,
the difficulty in adding the grey box that tells you you’re about to trigger the effect (though this is certainly not impossible with such a method), and
the change in the moment of triggering from after you release the button to during; this is a side-effect of the modern ability to drag a window itself rather than a wireframe. It would be hard to solve in any way that didn’t feel like a hack. strokinder points out why this is problematic.

The ability could also be implemented within the window manager itself. The advantages and disadvantages of this plan are mirror images of those of the other plan. It may, however, be worth the added complexity. Additionally, the loss of the portability inherent in using an external script may not matter: if this was implemented in Metacity itself, it would presumably be fairly easy to carry it over to Mutter, since in this area the systems differ little. Porting to Compiz may be more of a difficulty.

If anyone with a little programming experience would like to volunteer to work on this, abundant help can be provided; otherwise we will see about dealing with it when the bug queue is reduced a little. Please follow GNOME bug 607694, where this issue is being discussed.

Photo © Darwin Bell, cc-by.

Border widths under user control

At present, the width of a window’s border is decided by the current theme. However, some people find it harder either to see thin borders or to click on them. They would prefer thicker borders than most people want.

In addition, Metacity measures border widths in pixels. The higher the resolution of a display, the thinner the borders will appear, exacerbating the problem.

Of course, since borders are under theme control, one solution is to make a new theme; this is after all what we do for users who need high-contrast window borders. However, this modification will need to be made for every theme a user wants to use. Furthermore, the Metacity theme format is not easy for the general public to modify.

CSS themes would circumvent the problem by allowing widths to be specified in millimetres, rather than pixels. However, this is not currently supported by the underlying libraries, and even if it was, the problem of themes which still used pixels would remain.

GNOME bug 496536, which mirrors Launchpad bug 160311, discusses this issue. Two suggestions are made:

A setting to allow the user to override the width of borders. There is a patch to allow this, but it has not yet been committed. For example, here is the Crux theme with the border width set to 100 pixels.
Make “the mouse stick to the border”. If this means making the cursor pause briefly while moving over the border of a window, it may pose a problem with implementation.
A third suggestion, not made on either bug, is that the clickable area of a border should be a few pixels wider than its visible area.

Your chronicler would like to hear from readers who have this difficulty, particularly because of an accessibility problem, as well as your opinions on what should be done about the matter.

Photo © Lauren Marek, cc-by-nc.

Window matching experiment

At the Collabora party, Robert Ancell asked me how difficult it would be to implement window matching in Metacity. I decided this was an interesting question and spent an hour and a half today working on it. The results are now in the matching branch in GNOME git. If you’d like to download it and give it a try, please feel free.

It currently saves configuration data in a keyfile which contains one group per window, in this format:

[xlogo] x=287 y=178 w=250 h=231

This isn’t necessarily how it will end up: we could use GConf or perhaps some database-like format. It uses a modified version of the system suggested by Hongli Lai: if WM_WINDOW_ROLE is set, we use that to recognise the window, otherwise we use the window title– otherwise programs like xclock wouldn’t be matchable. The role or title is currently represented by the group name in the keyfile. The keyfile is saved at ~/.cache/metacity/matching.conf.

The system stores the position and size of every window at the moment it was closed. There is no need to edit configuration files by hand.

There are inevitably some caveats:

There is a bug such that when windows are restored they are offset by the size of the top-left hand corner of the frame. (In other words, the coordinates are misinterpreted as the client window’s position, not the frame’s.)
I haven’t tested this for scalability at all. Keyfiles might be very inefficient when you have hundreds of records for all I know.
It doesn’t know about workspaces, and it should; this will probably be the next thing I add.
If your window was minimised or maximised, this will not be restored, and it should be. This will probably be the next thing after that.
It might not be the best idea to write out the keyfile on every window close. Probably better to keep it in memory until the WM exits.
It might be useful to have a switch on the window menu to lock the position and size so it restores the same way when you reload it, in case you move it. On the other hand, this sounds like crack.

Should this branch be merged when the bugs are ironed out? Should it replace WM-based session files? These are good and interesting questions and ones we should discuss. Tune in next time, gentle reader! Or better, comment below.

Squib of the day: read your email

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.

Squib of the day: gentle fade

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.

Squib of the day: make the menu shorter

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.