Carsten Haitzler (The Rasterman) wrote:
On Sat, 25 Sep 2004 18:53:43 -0700 Milosz Derezynski <[EMAIL PROTECTED]>
babbled:

  
Carsten Haitzler (The Rasterman) wrote:

    
On Fri, 24 Sep 2004 21:41:00 -0700 Milosz Derezynski <[EMAIL PROTECTED]>
babbled:

 

      
Is it possible to do animations with only Evas (without using Edje), or 
at least with Edje, but without using EET?

For implementing winamp3/5 WAL skins i'd need animations but it's 
unfeasible to preprocess the WAL each time and create appropriate .eet 
files from it. Although that's an option that i would use if everything 
else fails (unhandy for the user etc...),i'd prefer to do without that.
   

        
actually - that'd be kind-of REALLY COOL. a WAL to EDJE converter :)


 

      
Yes it really would :)

The whole trouble with this that while most of Wasabi is opened, MAKI
(the scripting language, well as you probably know) is not. I will
reverse engineer MAKI when i have the UI part done.
    

hmm - let me guess. the scripting language is shipped as a bytecode binary
compiled version? or as source?

  
They come as compiled bytecode. Some WAL skins ship with the source, but that isn't guaranteed.
While the actual processing core of the language is in the free Wasabi part, the bytecode interpreter
engine is not, and that's what would be needed to reverse engineer.
Unfortunately many skins will just sit there without scripting and don't do much if anything at all.
Only a couple of actions are hardcoded, like PLAY, OPEN, BACK etc, VOLUME and so on, basically just the ones that Winamp 2 has by default



  
What i'm doing right now:

The code i linked to in a former post was just a test - Right now i'm
reworking it using GLib, Ecore/Evas and libxml2.

>From GLib i'm using only the GObject system and the signaling which is
more elaborated and flexible than Ecore's/Evas's (they do their job for
what they're meant, but i need more complex stuff for the WAL UI
backend). All the windowing and graphics are managed by Ecore_Evas, the
GLib/GTK main loop is not being used but rather the Ecore one. So in
fact i have hybrid GLib/Ecore/Evas objects and it works very well together.
    

god thats a mixup! you know signalling in edje is just done through a message
queue that is processed just before it goes idle? just put a message on the
queue - if the objects for which the message get deleted before the queue is
processed all the messages for that object are deleted (safely) even while
processing the queue- but its pretty easy to DIY :)
  
Yeah well.. it does work good so far. I'm having the GObjects merely to encapsulate the Evas and other data strctures, and i'm wrapping the Ecore signals into GObject ones. I'm not twisting the E* libs, just giving them another shell. So far works good :)

Reply via email to