Andreas wrote:
>>> The calculator works nice with edje_editor, but if I open it with
>>> edje_viewer it doesn't work. What is the preferred way to run
>>> "self-hosting" edje application?
>>>
>> What's the relevant notion of: "self-hosting" edje application?
>>
>
> My definition of "self-hosting" edje apps is an application that
> doesn't need any special C code to work. See the calculator that is
> referenced in the starting E-Mail from this thread.
>
>
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'.
The problem with this approach is that it doesn't provide a
means to 'theme' the 'app', unless one explicitly allows for that
ability as part of your notion of 'app'.
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).
One could also envision this notion in a manner similar to e17's
current modules minus the configuration widgets, or like the notion of
'themable-evas-objects' I've mentioned a couple of times, ie. shared
libs that have certain C function interfaces (such as 'add obj to an
evas', 'set a them file on an obj', 'set,get a property/value on an
obj', etc), or via scripting language modules of whatever sort.
One could think of these as self-determined rather than self-
hosting, and could be loaded by any program that knows the interfaces
they expose. It also gives a canonical notion of 'theme' file so that
one can theme these 'apps' - even though they may be self-determined,
one may still want to separate the gui aspects in such a way that the
'app' can be given different gui themes.
In general, there are many, many ways to imagine these kinds
of notions.. but even when things start out 'self-contained', they
often seem to end up wanting to become less and less so, in order
to allow for more flexibility, theming, modularization, etc.
>>> Maybe a plain C application that does
>>> only load an edj from command line should be delivered with edje.
>>> Maybe with options to define the backend engine. What do you think?
>>>
>>>
>> Besides needing to specify the display evas, one would also need
>> to specify the group to load in the edj file. But this would hardly be
>> enough in general to get meaningful things.. One would need to either
>> restrict to edjes which have a certain named group (say one called
>> 'main' or something) which is an expected wrapper for the 'edje app'
>> and a canonical entry point to the edj file, and it would need all the
>> 'code logic' to be done via scripting.
>> To go beyond that, one'd need a more flexible approach.. but
>> again, what do you want 'self-hosting edje app' to mean?
>>
-------------------------------------------------------------------------
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
