On Tue, May 6, 2008 at 1:50 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote:
> 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.
Jose,
The whole point of using Embryo instead of other VM is exactly that
you don't have any access to user's machine. I agree with that, I'd
avoid adding these calls, for such thing we can use Python or Ruby or
other scripting languages with full-system support, they have
different scope.
I think that Andreas idea is close to mine: allow users to have nice,
beautiful toys, that are really easy to make with pure-Edje/Embryo
today, as it was demonstrated by Dave's calculator. Another examples
would be calendar viewers, little games and more... Please don't
consider these "apps" like we're used to, I don't see any need for
themes, since you just need to get another app that looks like you
want.
That said, I see some room for improvement:
- some persistance, either sqlite or eet support from embryo,
allowing save minor state. This should be sandboxed as well;
- some call, could be a change of size hint -- see property and
callback, that would make the app host (ie: loader) to resize), maybe
calls to make it fullscreen;
- evas.inc (evas bindings for embryo);
- gettext.inc (gettext bindings for embryo), maybe make gettext
support transparent for strings... this would be a great addition to
Edje: add a flag to mark TEXT/TEXTBLOCK as translatable and pack .po
inside .edj
having http+xml (maybe xmlrpc for easy of use) would help, but would
make it more unsafe, the loader would have to specifically control
whenever the .edj would have such permissions, thus I don't think it's
something for now, but the above ideas are easy.
--
Gustavo Sverzut Barbieri
http://profusion.mobi
Embedded Systems
--------------------------------------
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
