The patch in GNOME bug 482354 (the one about windows which present to other workspaces, which almost every distro has included) was finally committed.
GNOME bug 83892, double-click to close, is still being argued over; your chronicler would like to hear some usability experts discuss the reasons given for its inclusion.
GNOME bug 565241 is a small change to Atlanta, the default theme.
GNOME bug 160311, requesting the ability to change border sizes independently of the theme, has finally gained a patch which may well be included.
GNOME bug 345233 has the rather pleasant idea that “Take a screenshot” should be added to the window menu.
GNOME bug 343824 is a request for the default maximisation keybinding to be a toggle, which seems reasonable.
GNOME bug 564343, Launchpad bug 298463, and others have said there’s a problem with the print screen button on some distributions. Still trying to track this one down.
GNOME bug 565409 believes there should be an option for alt-Tab to display all windows on all workspaces all the time. What do you think?
We’re not doing the “around the blogs” section this time because they’re mostly repeats of what’s gone before.
Launchpad bug 124326 requests a new titlebar button which minimises an application to the notification area rather than ordinary minimisation. Mostly this is currently done with the close button on the apps which support it, but some people feel it would be cleaner if these two functions were distinct. This action has been given the name “iconification” by some, but since this is the name the X specification gives to what we now call minimisation, I propose the ugly word “notifisation”.
The EWMH specification is going to have to include a way to tell which apps may be notifised, and a way for the WM to tell an app to notifise itself. This is going to require arguing out on wm-spec-list. In itself, this is not a major obstacle, but it’s important to be aware of.
It is unclear what the real difference between minimisation and notifisation is in practice. And if there is one, why shouldn’t all apps be notifisable?
Using the notification area for things other than ephemeral notifications– that is, using it as a cheap way to make panel applets– is contrary to the Human Interface Guidelines. Perhaps the HIG is wrong, but then we need careful thought before we give the practice a stamp of approval by enshrining it in the EWMH. Besides, there is talk of enforcing notification ephemerality.
Sometimes, as in GNOME bug 562650, people ask for extra buttons on the titlebar to go along with the standard set. On the face of it, if you may bind a keystroke to some action, there is no reason why you should not be allowed to add it to the titlebar. The problem is, though, that somehow it must be drawn with a recognisable icon. This has led to the current policy that all themes must declare all possible buttons, and that no buttons are allowed outside that set.
Version 1 of the theme standard required all themes to declare how to draw menu, minimize, maximize, unmaximize (restore), and close. Version 2 allowed the addition of shade, above (“always on top”) and stick (“on all workspaces”). If you’re looking to add one of those functions, as GNOME bug 562650 actually is, the solution is to switch to a theme which has a copy in version 2; unfortunately, there aren’t many which have adopted this version. Bright and Crux both support it, though:
But requiring a theme to contain all permitted buttons restricts the number of buttons which can reasonably be permitted. In the future, how can we permit any buttons to be added? We could require unknown as a button type, which would certainly solve the problem of not being able to draw a button, but the user who was faced with two or three buttons bearing question marks might object. Or we could allow buttons we didn’t know to be decorated with text saying, for example, “stick“, which would work but wouldn’t be beautiful.
Alternatively, we could require all possible buttons to be declared in the base theme, Atlanta, and simply allow fallback. This is reminiscent of the way fonts work: a font may contain any Unicode character, but most fonts don’t attempt to cover the whole range. This means that people wanting to write any language which includes characters outside the ASCII range would often run into holes in their words– so the system will use a glyph from another font as a substitute. This often leads to ugly rendering, though, even for names from a language as common and well-known as French:
He was Edmond Dant(oops!)s... and he was my father.Similar results would no doubt be common with a similar system for buttons.
At the moment i’m trying to make a theme for metacity but I have no idea how I can make the document icon drag-able and to interact with the desktop environment i.e. drag to the desktop to save or to the trash to delete.
Firstly, let me thank you for being willing to work on developing the desktop.
Secondly, there is nothing in Metacity corresponding to “the document icon” as such. It happens that most themes draw the icon of the current window on the menu button– the button which shows the window menu when you click it. Some themes do it other ways, though: for example, Atlanta draws the icon on the titlebar next to the window’s name. But let’s assume what we want is for the menu button to be draggable.
So you need to implement drag-and-drop from the widget representing that button. Once that’s done, you need to have a way to tell what should actually happen when the button is dragged somewhere. The trouble is that Metacity doesn’t know much about what’s actually in the window: it knows the name and the icon and a few other things, but the actual content is the business of the application. So you need to invent a way for the WM to tell the application that a drag is happening, and for the application to tell the WM what the data being dragged is, and what its type is. Then you need to argue it out on wm-spec-list and then you need to get applications actually to implement it so it’s useful.
So: this is possible, but it’s complicated and probably not an ideal first project. If you want to try solving it, please go ahead and I’ll give you what help I can. If you’d rather do something easier first and ramp up to this, I can help you with that too.
Apologies to subscribers of metacity-devel-list who have just had a dozen messages come through at once, and also to the authors of those messages for the time they spent in the queue. I didn’t have the password to administer the list; I do now. Now to actually answer them.
Matt Kraai noticed a stupid mistake in last night’s release, so this is a brown paper bag fix. It was too late at night to write anything sensible, clearly.
What is it ?
Metacity is a simple compositing window manager that integrates nicely
with GNOME 2.
What’s changed ?
Fixes to Thomas’s earlier fixes (Matt) (GNOME bug 562939)
What is it ?
