On Thu, 15 Jun 2006 15:06:00 +0900 Carsten Haitzler (The Rasterman) <firstname.lastname@example.org> wrote: > On Thu, 15 Jun 2006 15:11:28 +1000 David Seikel <email@example.com> > babbled: > > > One thing that will help with the icons is that some of those are > > SVG, and we have no SVG support. Probably because it's another > > sucky XML standard. I'm thinking of using xmlame to parse those and > > convert into bitmaps for generating .eaps. The other thing that > > will help is support for .xpm's, which is the other graphics format > > used in the fdo standards. > > xpms though are pretty sucky - no alpha channel, fat and bloated > ascii parsing etc. evas could have an xpm loader brought in from > imlib2. also in theory evas could have an svg loader brought in using > librsvg to load and render the svg as a bitmap (at a given > resolution). the problem is that evas has no way to DEFINE that > resolution you want it rendered at! :( but - i think thats doable - i > can add an evas_object_image_dpi_set() call where u can set the dpi - > this is then ONLY used by loaders loading vectorised (non-pixellated) > content as a way of knowing what resolution to render it as... > actually slight issue - dpi is fine for one kind of load and render, > but not if u don't know the PHYSICAL size of the svg first. i think > it will need a evas_object_image_render_size_set() that sets a > preferred rendering size in pixels... Per the fdo spec icon sizes have a default, the user can pick an override size to apply to all icons during menu generation, and there is an algorithm (already handled by e17genmenu) for picking a proper sized graphic if that size is not available, with fallbacks and other funsies. For vector images just render to that size. While on that subject, it will be good to have an fdo icon theme selector dialog, letting the user choose that override icon size and choose amongst the fdo compatible icon themes they have installed. I can take care of that too. B-) Also, since the the fdo spec says that .xpm and .svg file scan be used for icon graphics, it is likely that some .desktop files we find can only have their icon needs fulfilled by whatever .xpm or .svg file the distro installed with the .desktop. So if we support .desktop, we either support .xpm and .svg, or we put up with possibly many unfound icons. > anyway - it is solvable. we still have a problem with our eap caches > though. i am thinking of a possible move to a 1 big fat cache file > for every app e knows about only and no automatic update of it for > now (manual) and considering a possible move to support .desktop > files (but also allow .edj icons for them)... what do u think? One of the big issues with the current eap caches is triggered by e17genmenu, which is a very lengthy cache regen at the end. That would be solved by at the very least disabling the auto regen during e17genmenu's run. I haven't looked in depth at the cache code, so the rest of this is just ramblings off the top of my head. Users having to manually regen the eap cache is not a very user friendly option. Some of the regens can be triggered by code that knows when it has changed the eaps (eap_edit, e17genmenu, etc.). It's only when users manually intervene by moving eap files about that a manual regen needs to be triggered. A method to trigger regens from external tools combined with a method to manually regen and documentation that if a user knows enough to futz with the eaps manually, they should know to manually trigger the regen should work OK. Supporting .desktop files (and the fdo icon themes that go with them) as well as (possibly animated) .edj icons is a good idea. Currently there are no icon themes on get-e.org, since they where all taken down to be redone. That apparently is a very hard job as it has taken months with no result in sight. By leveraging fdo icon themes via .desktop files, we can make use of existing icon themes, some of which the average user probably already has installed by their distro. If we incorporate a search for .edj icons into the fdo search algorithm for .desktop files, we can have the best of both worlds. Then if the user happens to have a suitable .edj, it is used, otherwise use the fdo icon that would have been used anyway. > that's the stuff i have been hoping to never need in e17 - but punt > off to tools :) That means code to handle .desktop files needs to be used by E and those menu tools. Since I have already written the bulk of the code to deal with fdo .desktop files and icons I'm quite happy to shift it about so that it can be used by E and e17genmenu. Although if we put it into e_desktopfile.[ch] e17genmenu won't be able to access it unless I recast e17genmenu as a module. So the real questions becomes, where is the best place for .desktop support code so that E and other code can use it? IPC (here's the path to a .desktop, give me back a .eap)? In a library? I'm not real fussy, I just want to avoid duplicating the code. BTW, was efm ever meant to be used by third party tools?
Description: PGP signature