Freedesktop.org's Icon Naming specification became a center of contention for several days in May courtesy of a heated discussion on the XDG mailing list. At issue was whether the specification should enumerate a minimum contingent of icons for system-wide use, a comprehensive list, or something in between. The debate also raised questions about how the specification is crafted and, perhaps, what it means in light of Freedesktop.org's founding principle not to legislate standards.
The Icon Naming specification is a hierarchical set of named icons meant to be provided by a desktop environment like GNOME, KDE, or Xfce. The standard named icons include common functions such as opening and closing documents, and reusable components like the desktop's help browser. The specification defines a set of eleven contexts into which icons are grouped: actions, animations, applications, categories, devices, emblems, emotes, international, MIME types, places, and status. An application can take advantage of the system by referencing the named icons rather than having to embed its own copy of each icon it needs.
A related specification, the Icon Theme specification, shows how artists can create complete implementations of the set to install alongside the system's default. The Desktop base directory specification describes where in the filesystem applications should look for the icons provided.
Like many Freedesktop.org specifications and projects, the Icon Naming specification is discussed on the XDG mailing list (the name of which reflects Freedesktop.org's original name: X Desktop Group). May's debate was prompted by a request from PulseAudio's Lennart Poettering to add four new icon names to the devices context, representing common audio hardware devices (audio-headset, audio-headphones, audio-speakers, and audio-handsfree). Rodney Dawes, maintainer of the specification, countered with a different proposal he said would better fit the specification's existing hierarchy and not introduce unnecessary icons: a new icon for headset, replacing audio-card with speaker, making headphones a secondary icon named speaker-headphones, and dropping the audio- prefix from all of the names. Poettering defended his initial request, arguing that the audio- prefix should stay, and that speakers, headsets, and headphones were distinct enough form factors that they deserved separate icon names. When several weeks passed without a reply from Dawes, Poettering announced that he was going to use his proposed icon names anyway, bypassing the specification to talk directly to the distros, and suggested that Dawes hand over maintainership to someone else — reigniting the debate.
The back-and-forth then shifted from the original topic into a discussion of how the specification is maintained and updated. Critics of Dawes accused him of rejecting all requests for new icon names, and not listening to the needs of application developers. Dawes contended that the developer community seemed unwilling to provide input into the process; because the specification is intended to represent a community consensus, accepting a single developer's request for new icons without discussion would rapidly cause it to break down under a mountain of single-purpose icons. He had asked for input from other audio developers, he said, but received none.
Jakob Petsovits suggested that the specification did not need a formal process or maintainer at all, and that "if an icon is used by projects across different desktops and has a semantically clean purpose then that pretty much makes it 'approved' on its own." Marius Vollmer argued for creating another specification describing an "extra icon set" that would be separately maintained. Dawes then replied that such an extension mechanism already exists in the form of addenda to the Icon Naming specification, and expressed frustration that the community did not know of or take part in it.
Finally, talk turned to the purpose of the specification itself, with Dawes arguing that it "is a base specification, designed to be the minimal list of icons that everything else can fall back to. It is not going to have every little icon that ever random developer thinks needs to be in the spec for their app to have that icon. It doesn't make sense." Brian Tarricone responded that "the 'goals of the specification' (whatever the hell that means; inanimate documents don't have goals) are irrelevant. The needs of the community and of the people who will use the specification are paramount" and that "the goals of the spec don't fit what the developers need."
Tarricone's position seemed to be that the specification should try and be as inclusive as possible, trusting that the developer community would not suggest conflicting, confusing, or an excessive number of icon names. Dawes repeatedly pointed out that he was not opposed to adding new icon names, but felt that the developer community needed to weigh in on the merits of suggested additions, or else the specification would not reflect the community's consensus.
Thus, in different ways, both viewpoints do want the specification to be shaped by the community itself. They disagree on how best to implement that goal. Several pointed out that part of the problem is that icon themes by their nature involve both programmers and artists, two groups with very little overlap. Even among developers, who actively participate in the XDG list, individual change requests rarely elicit much response. As Tarricone asked in a subsequent message, "how do you get proper consensus for something where only one person seems to be working on a particular problem and needs icons for it?"
Participants in the discussion agreed that the informal mailing-list-only process was inefficient and led to proposals ending up in long-term limbo. Some suggested using wiki and bug-tracking software to manage proposed changes, but there is not yet a concrete plan for how to smooth out the process.
The diverging opinions about the purpose of the Icon Naming specification are limited to that specification alone, but they reveal another stumbling block — that despite producing specifications, Freedesktop.org is not a "standards body" in the traditional sense. Participation in any Freedesktop.org project is voluntary, and there is no attempt to enforce adherence to any specification it produces.
The group was founded in 2000 by Havoc Pennington (then at Red Hat) as a neutral place where projects and companies working on X-based desktop environments could meet to collaborate on common tasks. It currently provides hosting for several important Linux projects, including D-Bus, HAL, the X.Org server, and Compiz. Its other main activity, however, is producing cross-project specifications for system and application behavior. There are currently 50 specifications listed on the site's wiki, covering topics from desktop launchers to X extensions.
The Freedesktop.org mission statement emphasizes that it is not interested in "blessing" or legislating formal standards — a claim important enough to bear repeating on its specifications page. The fact that it produces specifications but makes no attempt to dictate their adoption places the group in an ambiguous position. As Pennington commented, "Freedesktop is basically a place people can document any consensus they may reach on interoperability. No rough consensus and it pretty much just gets stuck."
That may be frustrating for the participants, but for a completely voluntary-membership organization, it is unavoidable. In contrast, the Linux Foundation's Linux Standard Base has a formal workgroup, specification process, and certification.
Ted Gould, who weighed in on the confusion over the Icon Naming specification, summed up the Freedesktop.org distinction. "The reality is that most 'Freedesktop Specs' aren't really anything like IEEE Specifications or anything that typically is described using the word 'specification.' Really they all are more agreements on the way things do work in the code on the various desktops. But, in a truly open source way, code rules, so the only thing that really matters is who's implemented it as a vote yeah or nay on the spec." As the Icon Naming specification discussion recently showed, that process may not always be smooth.
Clusters and GridsRSPLIB is the Open Source implementation (GPLv3) of the IETF's new framework for Reliable Server Pooling (RSerPool), which is described in RFC 5351 to RFC 5356. If you a looking for a Grid comput[at]ion solution which is simple, easy to setup and mostly self-configuring, you are probably looking for RSerPool!"
Database Softwarecx_Oracle is a Python extension module that allows access to Oracle and conforms to the Python database API 2.0 specifications with a few exceptions." 6.0.11 will be the last release of 6.0. After this we will be transitioning into a New Release Model for the MySQL Server". This beta release fixes a number of issues with the first 8.4 beta, especially issues with pg_standby, PL/pgSQL and encoding and collation handling. We need all users to test 8.4 Beta 2 as soon as possible in order to speed the final release of the new version." announced. "Changes associated with this release include the following: * Fix a code generator bug introduced in version 3.6.14. This bug can cause incorrect query results under obscure circumstances. Ticket #3879."
Device DriversLIRC, the Linux Infrared Remote Control driver, has been announced. From the ChangeLog file: "ANNOUNCE, NEWS, configure.ac, doc/html-source/index.html, setup.sh: 0.8.5 release"
Printingannounced. "The third beta release of CUPS 1.4 includes many bug fixes, updated localizations for many languages, new logging features, and greatly improved Kerberos support."
Desktop EnvironmentsThis is the second update to GNOME 2.26. It contains many fixes for important bugs that directly affect our users, documentation updates and also a large number of updated translations. Many thanks to all the contributors who worked hard on delivering those changes in time. We hope it will help people feel better in their daily use of computers!"
ElectronicsRelease 3.2 is the beginning of the new stable branch series 3.2.x. Users who develop their GNU Radio applications to the 3.2 C++ and Python APIs will not need to change their source code to work with any of the releases along this line, though recompilation of C++ code may be needed." The release notes don't mention any changes.
Interoperabilityannounced. Changes include: "- More improvements to OLE copy/paste. - Beginnings of x86_64 exception handling. - Direct3D locking fixes. - ARB shaders improvements. - Better OpenGL pixel format support. - Various bug fixes."
Mail ClientsThe security fix to map_yp_alias in 1.4.18 turned out to be incomplete. We also exp[eri]enced some regressions in the updated filter plugin. Both are addressed in this new release 1.4.19 which contains a few other small fixes as well. If you do not use map_yp_alias or the filters plugin there's no urgent need to upgrade now if you already installed 1.4.18."
Music Applicationsguitarix is a simple Linux Rock Guitar amplifier for jack(Jack Audio Connektion Kit) with one input and two outputs. Designed to get nice thrash/metal/rock/blues guitar sounds. . . . Some new effect's in the amp section with new controllers, overworked tuner, overworked midi output (still it is experimental but can be useful for rhythm blues or jazz or. . . fun)"
Video ApplicationsThe PiTiVi team is proud to announce the first release in the unstable 0.13 PiTiVi series. This is the result of the past 6 months of intensive hacking. Over 700 commits of goodness awaits you."
Languages and Tools
CThe 4.4 branch is open under the usual release branch rules, a 4.4.1 release planned around June 21st. The branch seems to be in good shape and new bugs still get fixed quickly. There are a few bugs that I would block the 4.4.1 release for, including the reported ICE building SPEC on i?86. All seem to have patches though."
HaskellHaskell Communities and Activities Report has been published. "This is the 16th edition of the Haskell Communities and Activities Report. There are a number of completely new entries and many small updates. As usual, fresh entries are formatted using a blue background, while updated entries have a header with a blue background. Entries on which no activity has been reported for a year or longer have been dropped. Please do revive them next time if you have news on them."
PerlParrot is a virtual machine aimed at running all dynamic languages."
PythonThis is the third release candidate of the 2.5 version of Jython. It partially fixes JLine on Cygwin and fixes some threading issues. Almost every release in the past year has been followed shortly by another release to fix a windows bug. Today I finally got off of my butt and installed Windows on a VM and spent the day testing, so hopefully this one will not follow that pattern."
DebuggersCodeInvestigator is a tracing tool for Python programs. Running a program through CodeInvestigator creates a recording. Program flow, function calls, variable values and conditions are all stored for every line the program executes. The recording is then viewed with an interface consisting of the code. The code can be clicked: A clicked variable displays its value, a clicked loop displays its iterations."
EditorsPretesters: please send an email to me reporting success or failure on your build platform. In addition, please report bugs via M-x report-emacs-bugs, or send an email to email@example.com."
IDEs* Auto-import for from __future__ import with_statement will add a 'with' token instead of a with_statement token * Globals browser improved (only for Eclipse 3.3 onwards, older versions will have the old interface): o Can filter with working sets o Can match based on module names. E.g.: django.A would match all the django classes/methods/attributes starting with 'A'"
Version ControlThe smart server will no longer raise 'NoSuchRevision' when streaming content with a size mismatch in a reconstructed graph search. New command ``bzr dpush``. Plugins can now define their own annotation tie- breaker when two revisions introduce the exact same line."
Page editor: Forrest Cook
Next page: Linux in the news>>
Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds