From: Jose G. <jos...@ju...> - 2008-05-06 17:35:24
|
Gustavo wrote: >> >>> >> >> 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. > > Yeah, and it sounds like a fine 'security minded' approach.. but in practice it's not going to make much of a difference since edje is used along with all sorts of code that's highly insecure. What difference does it make that embryo itself can't access system calls when you have e17, e17-modules, all-sorts-of-apps/libs that use edje being written in C that can access anything and everything? Might as well have your 'scripting' language be able to do the same and restrict its use in edje itself to only 'safe' calls. The only way things will ever come close to a realistic notion of 'secure' will be when the host OS itself can be split into virtual, insulated versions of itself that are limited and private to a given user - far more than the current unix like permissions system gives. In any case, even if one wants to keep embryo to a limited VM (which is fine), there are still many ways in which its use with edje could be extended.. possibly even allowing for edje/edc and edje_cc to support other scripting languages - javascript could be good one. 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. > 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. > You may not see any need for themes now, but you/others may well see differently in time.. especially if more complex examples of such things became common. Re-usability and modularity eventually come forefront - whether it's at design/development time or at runtime.. and 'themes' are just one example of that. Replacing one 'toy' with another just to have it look somewhat differently may be fine for small toys.. but not everyone is going to limit themselves to wanting or writing only small toys.. and even then, theming will always be something people will want. Look at the entire history of guis, desktop or web related, and read the writing on the wall. :) > 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. > > Not before you finish that gl stuff you mentioned you wanted to play around with. :) |