[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Using freedesktop.org .desktop files.



On Tue, 08 Aug 2006 22:59:23 +0100 Essien Ita Essien
<essien@wazobialinux.com> wrote:

> IMOHO, i think the parsing part belongs to ecore, and the loading
> part to evas

I agree, parsing and loading.  We already have plenty of code for
loading images from a file, that's the easy bit.  I've spent most of
this morning staring at my code coming up with the exact places to cut
it to extract a neat block of parsing code.  The plan is to call that
from e_apps.c if it's trying to load a .desktop instead of a .eap.
e_apps.c is then in charge of loading the image file.  Entrance can use
it to load the details from the .desktop for it's own use.

> /me settles down to lazily wait for grossly underpaid onefang to
> solve all headaches :)

My paypal account is the same as this email account.  B-)


A few issues that have come up in IRC since I sent the original email -

We intend to extend the .desktop with support for edje files as well as
the PNGs and stuff.  A typical .desktop doesn't even have an extension
on the icon name.  I see no problem with simply looking for an edje
file of that name in the usual places before hunting the fdo specified
places for a PNG or whatever.  In fact, since I put it that way, I
realised there is no need to actually change the .desktop files
themselves, just add another level to the search.  In the end though,
most of the eaps I have seen are simple, static images based on a pre
existing PNG or GIF.

.eaps are fast and caching issues.  Hmm, given the never ending issues
with eap caching, that might not be as good as advertised.  raster
mentioned this, so he will have more to say on the issue.  This initial
part of the plan, where .desktop files are just another way to load the
same information that is in eaps means that once the information is in
the system, it gets cached in exactly the same way as eap derived
information.  App icons don't change very much, so this will have
exactly the same performance most of the time as the current system.
It's only the initial loading that may be slower.

All up, I don't think we loose any functionality, but we trade off a
little bit of speed before the information hits the cache, in exchange
for following the standard.  Following the standard means that there
are pre existing icon themes we can leverage, third party tools, and
distros already supply all we need to deal with the distro supplied
apps in exactly the same way as every other wm.  We still have the
ability to have edjy icons.

Attachment: signature.asc
Description: PGP signature