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

Re: [E-devel] E CVS: apps/e raster



On Thu, 15 Jun 2006 15:06:00 +0900 Carsten Haitzler (The Rasterman)
<raster@rasterman.com> wrote:

> On Thu, 15 Jun 2006 15:11:28 +1000 David Seikel <onefang@gmail.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?

Attachment: signature.asc
Description: PGP signature