[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] E lib submission
On Wed, 19 Apr 2006 15:09:15 -0700 (PDT) jerome Wilson <firstname.lastname@example.org>
> Greetings fellow E-landers.
> Over the easter weekend the aboundance of candy gave
> me a tase for eye-candy :),
> while browsing my home dir i fell upon ematrix written
> by Ibukun Olumuyiwa and i saw that it was sweet!!! :)
> Then it hit me wouldn't it be great if i could use it
> as a screensaver ... so after converting it to
> a Evas smart object and modifying some e17 code ... lo
> and behold it was delicious and i enjoyed it ( see
> screenshots in archive ).
> But then i pondered wouldn't it be wonderful if it
> could be plugable so i started on a journey that led
> me to ....
> modules, i then took a few minutes to figure out the
> best way to do it as a module, but, that soon ended
> when i
> realised that it would require too much work and i was
> So a few more minutes of brainstorming and ....
> Enter Esa.
> Esa stands for Esmart Animation (yeah the name kinda
> Basically it's a Evas smart object wrapped around
> regular evas code that can be loaded dynamically (did
> someone say plugin?).
> So the code once loaded can be manipulated as an evas
> Right now there are 3 demos available:
> - default : code taken from evas test written by
> Rasterman ( graphics by Raster?)
> - ematrix : code written by Ibukun Olumuyiwa (
> graphics by Ibukun?)
> - pixelman : code written by Rephorm ( graphics by
> Esa could loosely be compared to Edje running an
> animation in a loop.
> Esa modules being pure evas code, Esa can (well should
> haven't tested it yet ...) also be reused in it's
> Esa is not yet complete, it needs testing, pluging,
> filling, auto-tooling, and *ing :D
> I've already started testing in e17 by as that was my
> primary goal and it works pretty well,
> have a look in the screeshot dir for a "sneak peek".
> Get it here :
interesting idea - cool, in that you can have loadable modules for objects, BUT
one slight problem - the objects now are bound to 1 architecture only - the one
they are compiled for. i am not sure if this is a good idea or not. i would
have thought using something like embryo, implementing bindings for all the
useful evas/ecore etc. calls they could want (and still have them sandboxed so
they can't do any damage) then you can have small datafiles u can load that
work on any architecture - anywhere, and are "safe" to load... :)
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> enlightenment-devel mailing list
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) email@example.com
Tokyo, Japan (東京 日本)