enlightenment/enlightenment
enlightenment
/
enlightenment
10
9
Fork 12
Code Issues 24 Pull Requests 2 Projects Releases Wiki Activity

It's more complete now. 

SVN revision: 25571
This commit is contained in:
David Walter Seikel 2006-09-07 06:12:45 +00:00
parent ba23d3535d
commit be9dd395e1
1 changed files with 43 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
doc/FDO.txt
View File

@ -1,11 +1,26 @@
Enlightenment DR17 use freedesktop.org .desktop files according to the
Enlightenment DR17 uses freedesktop.org .desktop files according to the
XDG Desktop Entry Specification version 0.9.4, icon themes according to
the XDG Icon Theme Specification version 0.11, and menus according to
the Desktop Menu Specification version 0.92. There are some extensions
though.
the Desktop Menu Specification version 0.92. Everything is searched for
in paths specified by XDG Base Directory Specification version 0.6.
There are some extensions and gotchas though.
.desktop extensions.
Paths.
The spec wants us to run gnome-config and kde-config several times at
startup. This is currently #if'ed out and replaced with guesses. Lots
of guesses is a lot quicker than actually running those programs, and
often is good enough. The plan is to have an idle process run those
programs and fix the guesses.
A lot of distro specific quirks can be solved by adding more directories
and directory snippets to the ecore_desktop_paths code. The process of
eliminating non existing directories is quick, and only done once at
start up.
.desktop.
Two extension fields are defined as allowed by the specification.
@ -34,7 +49,7 @@ just copy the app/icon/class data to the X-Enlightenment-IconClass
field.
Icon theme extensions.
Icon theme.
.edj files are searched for before the other types of icon file. The
"icon" group is used to specify the graphics for the icon. It is up to
@ -42,3 +57,26 @@ the code using the result to allow full edje interactions and
animations, and people that write that code are encouraged to support it
all.
Menus.
The most complex, and thus the most problematic of the specifications.
The general philosophy is to err on the side of caution, giving the user
more apps in their menus rather than less. Even if that means some
duplicates and some things that aren't really apps.
There is often a .hidden menu, it contains various types of things.
Some of those things are supposed to be moved into proper menus by the
menu moving part of the spec. The menu moving code has not been
implemented yet. Following the above philosophy, it is shown to the
user.
Slackware and probably other distros use parent style menu merging.
Initially I did not write code to support that for two reasons. The
specification is confusing, and it takes some digging and cross
referencing other specs to sort out what it actually means. The other
reason is that distros available to me at the time for testing did not
use parent style menu merging, so there was no way to test it properly.
Now that I know of at least one distro that uses them, it's worthwhile
writing the code, and installing slackware under QEMU for testing.