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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel