parent
ba23d3535d
commit
be9dd395e1
48
doc/FDO.txt
48
doc/FDO.txt
|
@ -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.
|
||||
|
||||
|
|
Loading…
Reference in New Issue