diff options
| -rw-r--r-- | ChangeLog | 50 | ||||
| -rw-r--r-- | README | 16 | ||||
| -rw-r--r-- | basedir/.gitignore | 1 | ||||
| -rw-r--r-- | basedir/Makefile | 7 | ||||
| -rw-r--r-- | basedir/basedir-spec.xml | 137 | ||||
| -rw-r--r-- | menu/ChangeLog | 10 | ||||
| -rw-r--r-- | menu/menu-spec.xml | 16 | ||||
| -rw-r--r-- | systemtray/ChangeLog | 6 | ||||
| -rw-r--r-- | systemtray/systemtray-spec.xml | 68 |
9 files changed, 267 insertions, 44 deletions
diff --git a/ChangeLog b/ChangeLog new file mode 100644 index 0000000..0c70587 --- /dev/null +++ b/ChangeLog @@ -0,0 +1,50 @@ +=== No ChangeLog === + + Since this module is using git, we rely on commit messages to provide change + history. Please write commit messages in the format described at + http://live.gnome.org/Git/CommitMessages + + Below is a copy of this format: + +=== begin example commit === +tag: Short explanation of the commit + +Longer explanation explaining exactly what's changed, whether any +external or private interfaces changed, what bugs were fixed (with bug +tracker reference if applicable) and so forth. Be concise but not too brief. +=== end example commit === + + - The commit message is mainly for the other people, so they should be able + to understand it now and six months later. + + - Always add a brief description of the commit to the _first_ line of the + commit and terminate by two newlines (it will work without the second + newline, but that is not nice for the interfaces). + + - First line (the brief description) must only be one sentence and should + start with a capital letter unless it starts with a lowercase symbol or + identifier. Don't use a trailing period either. Don't exceed 72 characters. + + - You can prefix the first line with one tag, to make it easier to know to + which part of the module the commit applies. For example, a commit with + "fish: Make it work with newer fortune" in the gnome-panel module clearly + applies to the fish applet. + + - The main description (the body) is normal prose and should use normal + punctuation and capital letters where appropriate. Normally, for patches + sent to a mailing list, the body is copied from there. This main + description can be empty if the change is self-explanatory (eg: "Add DOAP + file"). + + - When committing code on behalf of others use the --author option, e.g. git + commit -a --author "Joe Coder <joe@coder.org>". + + - When referring to a bug, you can use this form: bgo#12345. Use bgo for + bugzilla.gnome.org, but you can also reference bugs in other bug trackers: + rh means bugzilla.redhat.com, bnc means bugzilla.novell.com, lp means + launchpad.net, etc. Whenever possible, use the full URL of the bug, though. + + - When a commit closes a bug, the commit message should contain a line like: + Closes: http://bugzilla.gnome.org/show_bug.cgi?id=12345 + or simply: + http://bugzilla.gnome.org/show_bug.cgi?id=12345 @@ -0,0 +1,16 @@ +xdg-specs +========= + +This repository contains the XDG specifications. + +To discuss the specifications, you may use the xdg mailing list: + + http://lists.freedesktop.org/mailman/listinfo/xdg + + +How to report issues +==================== + +Issues should be reported to the freedesktop.org bug tracking system: + + https://bugs.freedesktop.org/ (product Specifications) diff --git a/basedir/.gitignore b/basedir/.gitignore new file mode 100644 index 0000000..126e056 --- /dev/null +++ b/basedir/.gitignore @@ -0,0 +1 @@ +basedir-spec.html diff --git a/basedir/Makefile b/basedir/Makefile new file mode 100644 index 0000000..35a73df --- /dev/null +++ b/basedir/Makefile @@ -0,0 +1,7 @@ +all: basedir-spec.html + +%.html: %.xml + xmlto html-nochunks $< + +clean: + rm -f basedir-spec.html diff --git a/basedir/basedir-spec.xml b/basedir/basedir-spec.xml index fa8d2ba..e76673b 100644 --- a/basedir/basedir-spec.xml +++ b/basedir/basedir-spec.xml @@ -4,8 +4,8 @@ <article id="index"> <articleinfo> <title>XDG Base Directory Specification</title> - <releaseinfo>Version 0.6</releaseinfo> - <date>31 July 2003</date> + <releaseinfo>Version 0.7</releaseinfo> + <date>24th November 2010</date> <authorgroup> <author> <firstname>Waldo</firstname> @@ -16,23 +16,41 @@ </address> </affiliation> </author> + <author> + <firstname>Ryan</firstname> + <surname>Lortie</surname> + <affiliation> + <address> + <email>desrt@desrt.ca</email> + </address> + </affiliation> + </author> + <author> + <firstname>Lennart</firstname> + <surname>Poettering</surname> + <affiliation> + <address> + <email>lennart@poettering.net</email> + </address> + </affiliation> + </author> </authorgroup> </articleinfo> <sect1 id="introduction"> <title>Introduction</title> <para> - Various specifications specify files and file formats. This - specification defines where these files should be looked for by - defining one or more base directories relative to which files - should be located. + Various specifications specify files and file formats. This + specification defines where these files should be looked for by + defining one or more base directories relative to which files + should be located. </para> </sect1> <sect1 id="basics"> <title>Basics</title> <para> - The XDG Base Directory Specification is based on the following concepts: + The XDG Base Directory Specification is based on the following concepts: <itemizedlist> <listitem> <para> @@ -58,7 +76,7 @@ <listitem> <para> There is a set of preference ordered base directories relative to - which configuration files should be searched. + which configuration files should be searched. This set of directories is defined by the environment variable <literal>$XDG_CONFIG_DIRS</literal>. </para> @@ -66,11 +84,19 @@ <listitem> <para> There is a single base directory relative to which user-specific - non-essential (cached) data should be written. + non-essential (cached) data should be written. This directory is defined by the environment variable <literal>$XDG_CACHE_HOME</literal>. </para> </listitem> + <listitem> + <para> + There is a single base directory relative to which + user-specific runtime files and other file objects should + be placed. This directory is defined by the environment + variable <literal>$XDG_RUNTIME_DIR</literal>. + </para> + </listitem> </itemizedlist> </para> </sect1> @@ -92,32 +118,32 @@ </para> <para> <literal>$XDG_DATA_DIRS</literal> defines the preference-ordered set of - base directories to search for data files in addition to the + base directories to search for data files in addition to the <literal>$XDG_DATA_HOME</literal> base directory. - The directories in <literal>$XDG_DATA_DIRS</literal> should be seperated + The directories in <literal>$XDG_DATA_DIRS</literal> should be seperated with a colon ':'. </para> <para> If <literal>$XDG_DATA_DIRS</literal> is either not set or empty, a value equal to - /usr/local/share/:/usr/share/ should be used. + /usr/local/share/:/usr/share/ should be used. </para> <para> <literal>$XDG_CONFIG_DIRS</literal> defines the preference-ordered set of - base directories to search for configuration files in addition to the + base directories to search for configuration files in addition to the <literal>$XDG_CONFIG_HOME</literal> base directory. - The directories in <literal>$XDG_CONFIG_DIRS</literal> should be seperated + The directories in <literal>$XDG_CONFIG_DIRS</literal> should be seperated with a colon ':'. </para> <para> If <literal>$XDG_CONFIG_DIRS</literal> is either not set or empty, a value equal to - /etc/xdg should be used. + /etc/xdg should be used. </para> <para> The order of base directories denotes their importance; the first directory listed is the most important. When the same information is defined in multiple places the information defined relative to the more important base directory takes precedent. The base directory defined - by <literal>$XDG_DATA_HOME</literal> is considered more important than + by <literal>$XDG_DATA_HOME</literal> is considered more important than any of the base directories defined by <literal>$XDG_DATA_DIRS</literal>. The base directory defined by <literal>$XDG_CONFIG_HOME</literal> is considered more important than @@ -129,6 +155,48 @@ <literal>$XDG_CACHE_HOME</literal> is either not set or empty, a default equal to <literal>$HOME</literal>/.cache should be used. </para> + + <para> + <literal>$XDG_RUNTIME_DIR</literal> defines the base directory + relative to which user-specific non-essential runtime files and + other file objects (such as sockets, named pipes, ...) should be + stored. The directory MUST be owned by the user, and he MUST be + the only one having read and write access to it. Its Unix access + mode MUST be 0700. + </para> + <para> + The lifetime of the directory MUST be bound to the user being + logged in. It MUST be created when the user first logs in and if + the user fully logs out the directory MUST be removed. If the + user logs in more than once he should get pointed to the same + directory, and it is mandatory that the directory continues to + exist from his first login to his last logout on the system, and + not removed in between. Files in the directory MUST not survive + reboot or a full logout/login cycle. + </para> + <para> + The directory MUST be on a local file system and not shared with + any other system. The directory MUST by fully-featured by the + standards of the operating system. More specifically, on + Unix-like operating systems AF_UNIX sockets, symbolic links, + hard links, proper permissions, file locking, sparse files, + memory mapping, file change notifications, a reliable hard link + count must be supported, and no restrictions on the file name + character set should be imposed. Files in this directory MAY be + subjected to periodic clean-up. To ensure that your files are + not removed, they should have their access time timestamp + modified at least once every 6 hours of monotonic time or the + 'sticky' bit should be set on the file. + </para> + <para> + If <literal>$XDG_RUNTIME_DIR</literal> is not set applications + should fall back to a replacement directory with similar + capabilities and print a warning message. Applications should + use this directory for communication and synchronization + purposes and should not place larger files in it, since it might + reside in runtime memory and cannot necessarily be swapped out + to disk. + </para> </sect1> <sect1 id="referencing"> @@ -155,9 +223,9 @@ <listitem> <para> Lookups of the data file should search for ./subdir/filename relative to - all base directories specified by <literal>$XDG_DATA_HOME</literal> and - <literal>$XDG_DATA_DIRS</literal> . If an environment - variable is either not set or empty, its default value as defined by this specification + all base directories specified by <literal>$XDG_DATA_HOME</literal> and + <literal>$XDG_DATA_DIRS</literal> . If an environment + variable is either not set or empty, its default value as defined by this specification should be used instead. </para> </listitem> @@ -185,37 +253,37 @@ <listitem> <para> Lookups of the configuration file should search for ./subdir/filename relative to - all base directories indicated by <literal>$XDG_CONFIG_HOME</literal> and - <literal>$XDG_CONFIG_DIRS</literal> . If an environment - variable is either not set or empty, its default value as defined by this specification + all base directories indicated by <literal>$XDG_CONFIG_HOME</literal> and + <literal>$XDG_CONFIG_DIRS</literal> . If an environment + variable is either not set or empty, its default value as defined by this specification should be used instead. </para> </listitem> </itemizedlist> </para> <para> - If, when attempting to write a file, the destination - directory is non-existant an attempt should be made to create it + If, when attempting to write a file, the destination + directory is non-existant an attempt should be made to create it with permission <literal>0700</literal>. If the destination directory exists already the permissions should not be changed. - The application should be prepared to handle the case where the file - could not be written, either because the directory was non-existant - and could not be created, or for any other reason. In such case it + The application should be prepared to handle the case where the file + could not be written, either because the directory was non-existant + and could not be created, or for any other reason. In such case it may chose to present an error message to the user. </para> <para> When attempting to read a file, if for any reason a file in a certain - directory is unaccessible, e.g. because the directory is non-existant, + directory is unaccessible, e.g. because the directory is non-existant, the file is non-existant or the user is not authorized to open the file, - then the processing of the file in that directory should be skipped. - If due to this a required file could not be found at all, the + then the processing of the file in that directory should be skipped. + If due to this a required file could not be found at all, the application may chose to present an error message to the user. </para> <para> - A specification that refers to <literal>$XDG_DATA_DIRS</literal> or - <literal>$XDG_CONFIG_DIRS</literal> should define what the behaviour - must be when a file is located under multiple base directories. - It could, for example, define that only the file under the most + A specification that refers to <literal>$XDG_DATA_DIRS</literal> or + <literal>$XDG_CONFIG_DIRS</literal> should define what the behaviour + must be when a file is located under multiple base directories. + It could, for example, define that only the file under the most important base directory should be used or, as another example, it could define rules for merging the information from the different files. @@ -223,4 +291,3 @@ </sect1> </article> - diff --git a/menu/ChangeLog b/menu/ChangeLog index b46d43a..025e9e1 100644 --- a/menu/ChangeLog +++ b/menu/ChangeLog @@ -1,3 +1,13 @@ +2009-01-10 Vincent Untz <vuntz@gnome.org> + + * menu-spec.xml: bump version to 1.1-draft + +2009-01-10 Vincent Untz <vuntz@gnome.org> + + * menu-spec.xml: add LXDE as registered desktop environment for + OnlyShowIn. + See http://lists.freedesktop.org/archives/xdg/2008-December/010103.html + 2007-08-18 Vincent Untz <vuntz@gnome.org> * menu-spec.xml: accept X-Foo for environments in diff --git a/menu/menu-spec.xml b/menu/menu-spec.xml index 9b75e0f..67365d7 100644 --- a/menu/menu-spec.xml +++ b/menu/menu-spec.xml @@ -1,6 +1,6 @@ <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [ - <!ENTITY version "1.0"> + <!ENTITY version "1.1-draft"> <!ENTITY dtd-version "1.0"> ]> @@ -8,7 +8,7 @@ <articleinfo> <title>Desktop Menu Specification</title> <releaseinfo>Version &version;</releaseinfo> - <date>6 February 2007</date> + <date>23 June 2010</date> <authorgroup> <author> <firstname>Waldo</firstname> @@ -1348,7 +1348,7 @@ <tbody> <row> <entry>AudioVideo</entry> - <entry>A multimedia (audio/video) application</entry> + <entry>Application for presenting, creating, or processing multimedia (audio/video)</entry> </row><row> <entry>Audio</entry> <entry>An audio application</entry> @@ -1368,7 +1368,7 @@ <entry>A game</entry> </row><row> <entry>Graphics</entry> - <entry>Graphical application</entry> + <entry>Application for viewing, creating, or processing graphics</entry> </row><row> <entry>Network</entry> <entry>Network application such as a web browser</entry> @@ -1517,17 +1517,17 @@ </row><row> <entry>VectorGraphics</entry> - <entry>Vector based graphical application</entry> + <entry>Application for viewing, creating, or processing vector graphics</entry> <entry>Graphics;2DGraphics</entry> </row><row> <entry>RasterGraphics</entry> - <entry>Raster based graphical application</entry> + <entry>Application for viewing, creating, or processing raster (bitmap) graphics</entry> <entry>Graphics;2DGraphics</entry> </row><row> <entry>3DGraphics</entry> - <entry>3D based graphical application</entry> + <entry>Application for viewing, creating, or processing 3-D graphics</entry> <entry>Graphics</entry> </row><row> @@ -2072,6 +2072,8 @@ </row><row> <entry>KDE</entry><entry>KDE Desktop</entry> </row><row> + <entry>LXDE</entry><entry>LXDE Desktop</entry> + </row><row> <entry>ROX</entry><entry>ROX Desktop</entry> </row><row> <entry>XFCE</entry><entry>XFCE Desktop</entry> diff --git a/systemtray/ChangeLog b/systemtray/ChangeLog index 7acaf3a..9487095 100644 --- a/systemtray/ChangeLog +++ b/systemtray/ChangeLog @@ -1,3 +1,9 @@ +2009-01-10 Vincent Untz <vuntz@gnome.org> + + * systemtray-spec.xml: add _NET_SYSTEM_TRAY_VISUAL and a description of + visual and background pixmap handling.. + See http://lists.freedesktop.org/archives/xdg/2009-January/010122.html + 2004-11-30 Mark McLoughlin <mark@skynet.ie> * systemtray-spec.xml: add _NET_SYSTEM_TRAY_ORIENTATION. diff --git a/systemtray/systemtray-spec.xml b/systemtray/systemtray-spec.xml index d264343..669f3d0 100644 --- a/systemtray/systemtray-spec.xml +++ b/systemtray/systemtray-spec.xml @@ -5,8 +5,8 @@ <article id="index"> <articleinfo> <title>System Tray Protocol Specification</title> - <releaseinfo>Version 0.2</releaseinfo> - <date>23 November 2004</date> + <releaseinfo>Version 0.3</releaseinfo> + <date>10 January 2009</date> <authorgroup> <author> <firstname>Havoc</firstname> @@ -206,6 +206,39 @@ void send_message( </para> </sect1> + <sect1 id="visuals"> + <title>Visual and background pixmap handling</title> + <para> + If the _NET_SYSTEM_TRAY_VISUAL property (see below) is present, + tray icon windows should be created using that visual. If the + property is not present, then tray icon windows should be + created using the default visual of the screen. + </para> + <para> + Historically, to allow the appearance of icons with transparent + backgrounds on servers that did not support visuals with an + alpha channel or the Composite extension, a convention was + adopted where a background pixmap was set on the XEMBED embedder + window, aligned properly to match the contents of the embedder + window's parent, the tray icon window was set to have a + background of ParentRelative, and drawing of the icon done on + top of this background. + </para> + <para> + Setting the background of a window to ParentRelative when the + depth of the window does not match the depth of the window's + parent, or reparenting a window with a ParentRelative + background into a parent with a non-matching depth produces a + BadMatch error, so the embedder window must be created to match + the visual of the tray icon window, even if the tray icon window + does not have the visual provided in _NET_SYSTEM_TRAY_VISUAL. If + convenient, the tray manager may set an appropriate background + pixmap on the embedder window to provide the appearance of + transparency. However, the preferred method of transparency is + to use a visual with an alpha channel in _NET_SYSTEM_TRAY_VISUAL. + </para> + </sect1> + <sect1 id="hints"> <title>Tray icon hints</title> <para> @@ -280,6 +313,24 @@ icon contents should be laid out. </para> </sect2> + + <sect2> + <title>_NET_SYSTEM_TRAY_VISUAL</title> + <programlisting><![CDATA[ +_NET_SYSTEM_TRAY_VISUAL visual_id VISUALID/32 +]]> + </programlisting> + + <para> +The property should be set by the tray manager to indicate the preferred +visual for icon windows. To avoid ambiguity about the colormap to use +this visual must either be the default visual for the screen or it +must be a TrueColor visual. If this property is set to a visual with +an alpha channel, the tray manager must use the Composite extension to +composite the icon against the background using PictOpOver. + </para> + + </sect2> </sect1> <sect1 id="balloon"> @@ -353,6 +404,19 @@ icon contents should be laid out. <appendix id="changes"> <title>Change history</title> <formalpara> + <title>Version 0.3, 10 January 2009, Owen Taylor</title> + <para> + <itemizedlist> + <listitem> + <para> + Added the _NET_SYSTEM_TRAY_VISUAL hint and a + description of visual and background pixmap handling. + </para> + </listitem> + </itemizedlist> + </para> + </formalpara> + <formalpara> <title>Version 0.2, 23 November 2004, Mark McLoughlin</title> <para> <itemizedlist> |