[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 09:44:09 -0500 brian.mattern@gmail.com babbled:

> 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
> > <noreply@cvs.enlightenment.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.

this feels sooo dirty - what if the icon uses multiple images in the .edj. this
is currently bothering me as it simply doesn't make it sane to do without
entirely decompiling the edje then recompiling.

> So, 
> 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
> compressed).
> (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
> part {
>   name: "icon";
>   type: IMAGE;
>   description {
>     ...
>     image {
>       normal: "xterm.png";
>       image_class: "icon";
>     }
>   }
> }
> then, e would do something like
> edje_object_image_class_set(eap_obj, "icon",
> "/path/to/fancy-xterm.png");
> 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 :)

indeed. i'd rather just.. keep clear of it for now.

> --
> rephorm
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
Tokyo, Japan (東京 日本)