[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:11:28 +1000 David Seikel <firstname.lastname@example.org> babbled:
> On Thu, 15 Jun 2006 00:21:09 -0400 (EDT) Enlightenment CVS
> <email@example.com> wrote:
> > if we want to do icons on the desktop - and as part of efm, i am
> > thinking that we have little choice but to implement a .desktop file
> > loader. this is not to hard - it's the xml jungle of the system menus that
> > is sucky. the real problems are where to find the icons for the .desktop
> > files.
> The xml jungle of the systems menu and where to find icons for .desktop
> files is almost a solved problem in e17genmenu. Guess I should give a
> progress report. I am currently distracted by non E things, but I will
> get back to e17genmenu soonish.
oh definitely - i am considering this as an orthogonal issue. :) ie building
the menu - what items go where in what order is the "xml jungle" the actual
items themselves are .desktop files :) looking at the issue at hand i was
looking at (thinking about) we'd need .desktop support in efm for displaying
contents of dirs that happen to have been modified by other fm's
> e17genmenu currently does the basic unravelling of fdo xml system menu
> morass, but not any of the "but put this menu item over there instead of
> over here" shuffling. This means that everything is in the menus, but
that's the stuff i have been hoping to never need in e17 - but punt off to
> some are not in the right place, and some extra stuff will be in the
> menus (some deletions are ignored). It does a reasonable job of
> finding icons for .desktop icons but could be better, and needs lots of
> cross platform testing. The big problem with sucky standards is that
> everybody implements them differently, so I have to tweak it to work
> with more and more implementations as I find ones that it doesn't work
yeah. that really sucks :(
> I'm very pleased with the performance of xmlame, the worlds lamest xml
> parser. It does what is needed for parsing fdo xml menu files, and
> nothing else. It works really fast. I'm not so pleased with the speed
> of .eap creation. It uses a combination of engrave to create the
> initial .eap, followed by eet calls to fill in the extra details.
> This involves starting an executable and opening / closing the
> eap several times. This is fine for one or two .eaps, but when you are
> creating hundreds the overheads involved slow things down a lot.
yup - lots of executions etc. edje_cc isn't intended to be speedy either -
though most of its overhead is in writing out the edje file and compressing
image data etc.
> Since my e17genmenu rewrite was always with an eye to incorporating it
> as part of apps/e, I have no problem doing so to take care of this TODO
> item. That's why I implemented my own xml parser, and that's one of the
> reasons I want to get rid of the engrave dependency.
excellent. .desktop file parsing could be brought in as e_desktopfile.[ch] or
> 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...
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?
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) firstname.lastname@example.org
Tokyo, Japan (東京 日本)