Archivos para mayo 2006

Basic directories in specs

27 mayo 2006

There is another specification in freedesktop that indicates where are located the files, that are refered in other specifications, in the user disk. The following table shows the possible environment variables that are refered in other specs, the value to be used for each of them if they are not present, or empty, and a short description of their meaning:

Environment Variable Default value Meaning
$XDG_DATA_HOME $HOME/.local/share base directory relative to which user specific data files should be stored
$XDG_DATA_DIRS /usr/local/share/:/usr/share/ preference-ordered set of base directories to search for data files in addition to the $XDG_DATA_HOME base directory
$XDG_CONFIG_HOME $HOME/.config base directory relative to which user specific configuration files should be stored
$XDG_CONFIG_DIRS /etc/xdg base directory relative to which user specific configuration files should be stored
$XDG_CACHE_HOME $HOME/.cache base directory relative to which user specific non-essential data files should be stored

Anyway they won’t be necessary until we begin with the menu stuff.

Dukelele’s band

26 mayo 2006

watch hideya kawahara and yuichi sakuraba play the dukelele

.desktop files internationalization

26 mayo 2006
In my last post I spoke about the basic format of .desktop files. If you remember, this files where composed of two elements, one the category header and the other key/value pairs that holded multiple information about the associated Desktop Entry.

Specification includes means to localize certain keys in the file so it may contain information to be shown to the user (i.e. name, description,…) that must be localized, this are the keys wich value type is declared as localestring.

The approach is easy, we have one “primary” key that holds the default localized value (normally in english) and then add more keys with the same name suffixed with the corresponding POSIX locale in brackets. For example we should have the key

Name=Menu Editor

with the keys

Name[ca]=Editor del menĂş
Name[cs]=Editor nabĂ­dky
Name[cy]=Golygydd Dewislen

following it. If the current locale is not found in the file, the default key must be used.

The way this entries are encoded (ISO-8859-1, UTF-8,…) comes defined in the .desktop file using the Encoding required key. This key can take two possible values : UTF-8 of Legacy-Mixed. While the later is deprecated, it’s still possible to find it (I think) in some systems, so let’s see how it works.

When the Legacy-Mixed mode is active for a file, localized keys are encoded using old style encoding (ie not UTF-8). In this files the POSIX Locale that’s used to identify each localized key is used to determine the encoding. Following table shows what encodings correspond to each Locale :

Encoding Aliases Tags
ARMSCII-8 (*) hy
BIG5 zh_TW
CP1251 be bg
EUC-CN GB2312 zh_CN
ISO-8859-1 br ca da de en es eu fi fr gl it nl no pt sv wa
ISO-8859-2 cs hr hu pl ro sk sl sq sr
ISO-8859-3 eo
ISO-8859-5 mk sp
ISO-8859-7 el
ISO-8859-9 tr
ISO-8859-13 lt lv mi
ISO-8859-14 cy ga
ISO-8859-15 et
KOI8-R ru
KOI8-U uk
TCVN-5712 (*) TCVN vi
TIS-620 th
( Table directly copied from the standard )
Encodings that are marked with an asterisk are very rare and are not supported by the GNU C library, so maybe they are neither supported by Java. Anyway, as they are so rare and the legacy mode is to be extincted it doesn’t look like a problem to really care about.

Basic .desktop file format

24 mayo 2006
The .desktop files are the basic entities that are used to build the desktop and the menu in specification. These are plain text files with “group” headers of the form [GROUP_NAME], where delimiters [ and ] obviusly cannot be contained within GROUP_NAME, and pairs of keys and values with different meanings and restrictions that we’ll see in another posts. All the pairs found right after a group header belongs to this group, so pairs are categorized in each desktop entry. Every valid .desktop file must start with the same group, namely [Desktop Entry].

The specification includes also classical bash-style comments (lines starting with #) that are to be ignored by implementations. Specs also indicate that implementations must ignore and preserve items they can’t handle, wich gives us the posibility of adding some homegrown properties for the files (Z-Depth, DefaultIconAnimation…), we’ll see later on.

Each key/value, so called entry, in the file should have the format:


With spaces trimmed from the beginning and the end of the Key and the Value, and using = as delimiter (can’t be used inside a key/value). There are some escape sequences supported in the entries: \s (space), \n (newline), \t (tabulator), \r (carriage return) and \\ (backslash). Some keys can have multiple values that should be separated by a semicolon, and ended by one ; also. To put a semicolon in a single value it has to be escaped \; .

Value types are constrained to : string, localestring, regexp, boolean (true/false) and numeric values, from which the strings are ASCII characters and localestring are UTF-8 encoded values (except if something called Legacy-Mixed Encoding is enabled, but we’ll talk about it in another post).

Later more

My Summer of Code blog

24 mayo 2006

Just leave a note that i’ve been accepted for the Google‘s Summer of Code 2006 to create an implementation of the freedesktop standards for menu&desktop regeneration into the Project Looking Glass (You can take a look at my proposal here) and that i started another blog with the purpose of following my work on the summer.


24 mayo 2006
Well, I have finally been accepted for the Google‘s Summer of Code 2006 to create an implementation of the freedesktop standards for menu&desktop regeneration into the Project Looking Glass (You can take a look at my proposal here).

First I would like to thank all guys at LG3D that considered me good enough to work with them once again (I also participated in last year’s SoC), so Hideya, Deron, Paul, Krishna, Radek and whoever participated in ranking:


This goes also to Google itself and to all people there that are so patient with hot-young-hormones (namely,at least, Chris DiBona, Greg Stein and Leslie Hawthorn)

PS: Expect some updates soon in this blog

Schwartz says the GPL is *on* the table for Java

23 mayo 2006
Mr.Jonathan Schwartz (Sun’s CEO) says in his blog that:

But all in all, a really great week – we’re now making serious progress
on open sourcing Java (and despite the cynics, using a GPL license is
very much *on* the table), while focusing the debate on what matters
most: not access to lines of code (that’s already widely available), but ensuring compatibility.”

Who says Sun is not open?