>>>> Then one needs to extend edje/embryo scripting far more than
>>>> it's currently capable of.. and for it to be sufficiently capable
>>>> for general kinds of 'apps' it may need to have access to system
>>>> calls and other things. One'd also need to have well-known entry
>>>> points into the .edj file - either a special main group or a special
>>>> script function to execute on load or some such, and have all being
>>>> executed in some kind of 'runtime'.
>>>>
>
> i have plans to do this with edje. it'd actually be very simple. the plans go
> like this:
>
> 1. allow edje objects to be ONLY defined by embryo script. right now you can
> specify a message handling callback for an object and then script sections
> when
> events (programs) get triggered. there is always one on load so it's easy to
> run code when the object is loaded for setup etc. etc. but i want to go
> further
> and add a resize() callback and a part_text_set() callback and then the code
> logic here handles all of that.
> 2. combined with #1 above add more hooks for the script to be able to CREATE
> and
> DESTROY and MANIPULATE evas objects directly. edje would track these make sure
> they are cleaned up on object destruction and maybe enforce limits (like no
> more
> than 1000 objects or some user settable limits).
> 3. add the ability to load other edje objects from the same file, so you can
> mix and match the older layout and declarative way of doing objects and the
> script/code way.
> 4. add a few more calls like adding/deleting pollers
>
>
It's interesting that Flash seems to have originally centered
around AS, but Flex is more about a balanced combo of AS plus a
declarative xml syntax and css (plus their designer/builder apps
of course), and this is what most others do as well (except possibly
JavaFX).
Anyway... yeah, extending embryo scripting to allow for more
dynamic handling of "edje/evas objects" would be very useful, but I
think you're going to want the ability to 'load' objects from other
edj files as well.. or at least have edje itself load such other files
and let embryo functions get whatever groups/parts it needs from
that file.
One could argue that edje should *optionally* allow for
other scripting languages (ie. optionally compiled, loadable mods),
after all one could extend edje to support python or javascript
in an extended edc with such added scripts.. but that would mean
duplicating a lot of edje code, so why not add it as optional modules,
etc.
But one could instead argue that one keep whatever script/code
logic separate from the initial ui/gfx description, and have the
code load that external edj/eet/whatever file and work with that.
But for this to work best it'd mean that the script/code would really
need to go *beyond* what the edje api provides.. into the realm of
what the "edje-edit" api has, so that one can dynamically create/modify/
destroy edje/evas objects (as you mentioned).
In the end, I'd probably agree with this latter approach, especially
for more complex stuff.. ie. separate code logic which uses other resource
file(s) for its initial gfx-ui description (and it's basically what I'd
meant with themable-evas-objects for C code, though it could be done with
scripting too).
> this should allow you to pretty much do anything that flash does with
> actionscript, BUT only locally within a limited sandbox. i do NOT intend to
> add
> network access or any filesystem access or anything else - this is dangerous.
> you download and use a theme (blindly) and suddenly it's reading your emails
> and
> sending them of to someone else. themes are NOT programs. they are not meant
> to
> be. you should not have to even think of security with them. at worst they
> should just be annoying and useless.
>
>
>>>> Note that things like Flash/mxml (then to swf) or Silverlight/
>>>> xaml (may also have some binary representation), unlike edje/edc,
>>>> have extensive 'script' language support and allow for separating
>>>> the code logic from the 'gui' part in separate files if desired
>>>> (though I suppose one could do this with edje/edc/embryo).
>>>>
>
> edje is not far of there. see above. it needs just a few calls and exporting
> some evas and edje controls and bingo. you can do just the same. embryo is a
>
Errrr... modulo some gfx bits that are still not in evas, and
a fairly flexible animation framework, and video/multimedia stuff...
and a browser plugin... :)
>> Alternatively, there's no need that edje should be everything to
>> everyone, and it might be better to have other things address further
>> needs, eg. evolve/edc for more involved widgets, maybe other animation
>> mechanisms, etc.
>>
>
> it should help abstract the ui from the code. it should not become the code.
> as
> above. i have had plans for a long time and will get to them eventually - it's
> all easy to do. i just have no NEED for it right now, and have other things to
> do, so i haven't done it.
>
PS.
Didn't someone send some edje/embryo extensions recently?
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
