[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 00:21:09 -0400 (EDT) Enlightenment CVS
<noreply@cvs.enlightenment.org> 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.

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
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
for.

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.

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.

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.

Attachment: signature.asc
Description: PGP signature