On Tue, 08 Aug 2006 22:59:23 +0100 Essien Ita Essien <firstname.lastname@example.org> 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.
Description: PGP signature