[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] E CVS: apps/e raster
On Thu, Jun 15, 2006 at 03:11:28PM +1000, David Seikel wrote:
> On Thu, 15 Jun 2006 00:21:09 -0400 (EDT) Enlightenment CVS
> <firstname.lastname@example.org> wrote:
> 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.
Right now, most .eap creation (iirc) is done one of two ways:
1) Have some edc code that replace some values in and write out to a
file, then call edje_cc on it.
2) Use engrave to load an existing .edj / .edc, use its API to modify
things, and save it out (which rebuilds .edc, and calls edje_cc on it).
Since for .eaps, the only things chaning are the image and the extra metadata fields (exe, class, etc), it might be quicker if we simply used eet directly to write out the image data to the image/0 key (without touching the edje blob). We'd have to make sure we used the proper compression, but that shouldn't be too difficult. We could even make this a generic '.edj image swapping' tool.
Load up a template .edj
Display a list of images in the ejde's image directory (reading in the
compression, etc also).
Allow new image files to be specified for each of these
On 'Save', copy the template to the new location, replace out the
images/0, images/1, etc keys with any new ones selected (properly
(for .eaps you'd have the additional metadata fields to replace also)
This way the .edc wouldn't have to be parsed / compiled each time.
Something like this just seems cleaner to me, and would allow
alternate styles (multistate icons maybe?) to be generated.
One other (harebrained) option would be to add in something like "image
classes", where you could set a different image file (somewhere on disk)
for edje to load instead of the one in the .edj file.
e.g. the icon part would be somethink like
then, e would do something like
After thinking about this a bit more, its seeming less harebrained...
What do you guys think?
> 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.
eek! parsing svg might be easy, but DRAWING it? scary :)