pieterg wrote: > On Saturday 02 May 2009 22:08:27 Gustavo Sverzut Barbieri wrote: > >> On Sat, May 2, 2009 at 4:15 PM, pieterg <piet...@gmx.com> wrote: >> >>> On Saturday 02 May 2009 19:26:00 Gustavo Sverzut Barbieri wrote: >>> >>>> On Sat, May 2, 2009 at 1:28 PM, pieterg <piet...@gmx.com> wrote: >>>> >>>>> How about if we allow the use of "group:signal" as signal name? >>>>> I've implemented this as a test, and it works like expected. >>>>> >>>> I don't know if it would break things, possibly you better do check if >>>> there is a part with that id and it is GROUP in order to avoid >>>> breaking existing apps that may use ":" in the name. >>>> >>> OK, good point. So something like this perhaps? >>> >> mostly. I liked your patch, but committed a slightly different version >> that does only one strchr() and uses strdupa() instead of strdup() as >> strings live for short time and are rather small. >> >> I also changed it to use the part name, not the source name as usually >> you can have more than one part using the same group/source. See >> attached example. >> > > Indeed, I was in doubt about whether to use the part name or the source > name, changed it to the source name the last minute. But in order to allow > the same group to be swallowed several times, we need to use the part name, > as you say. >
That ability was part of what was intended in the original design. There were other apects that I recall discussing with rephorm at the time.. but can't recall just exactly what those were anymore. There was one other fairly simple extension I do recall we discussed at the time: we wanted to add to edje (along similar lines) the ability to embedd other descriptively defined 'objects' via loadable modules and the basic swallow mechanism. This was to add a new "OBJECT" part type, whose main decription would have two attributes, say "module" and "src". Thus for example one would have as part of an OBJECT part description: module: "module_name"; src: "some uri"; The 'module' would refer to an "edje object module" which would simply be a loadable lib which has a few basic interfaces. For example, besides the usual module init/shutdown funcs, they must also expose an "add" function of the form: Evas_Object *(*add)(Evas *evas); and a "file set" function of the form: void (*file_set)(Evas_Object *obj, const char *uri); and this is what the 'src: "some uri";' would refer to for being 'set'. Further refinements of this are possible, but just with this one can extend edje in some interesting and non-trivial ways which many can use. For example, most any smart class you can define that would allow for the smart objs it creates to have a file 'set' on its instances... say eg. an "svg" module, where one sets .svg docs as the files.. or say some kind of 'gadget' module where you set a .edj file as a theme... or many, many such kinds of things. Very similar of course to the html <object> tag and other such. Since these modules can do much more than use 'sandboxed' scripts, it might also be nice to add an edje api func to disable loading any object modules, or 'unknown' ones somehow, etc. This is all fairly straightforward to implement, if desired. ____________________________________________________________ Want more out of life?? Fast track your career with an online degree. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTKL6dobI0ICbt3elKJ0bxR9DVnlLJFOZtlrQNbZUgKsdcQ9mpncC8/ ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
