From: Gustavo S. B. <bar...@pr...> - 2009-07-29 22:51:52
|
Hello all, I'm planning to bootstrap the guarana + elementary merge* soon** but I want to solve an unsolved problem first: help bindings and users of evas_object_smart_callback*. If you're out of time to read it in detail, skip to end and read "Summary" at least. = Problem = Evas smart objects can emit signals with data, but these are free-form. Nobody knows which signals are emitted or which type of data they carry. This makes life of users harder since they have to grep for code or hope that there is documentation and it's up to date, which is quite hard we know. For bindings it's even worse, as we have to do it and write specific mappers for each signal, that's very boring and error prone. = Solution = I would like to avoid breaking current code, so changing things drastically is a no go. I could also propose a new system with signal inheritance and index access to speed up dispatching and all, but I guess the best is to build on top of existing stuff as it's "fine" for our use cases. The proposal is to add an array/list of signals-types to Evas_Smart_Class. This array would be defined when class is created and should not be changed afterwards. Types would be DBus-like type strings (http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-signatures), for example "iis" is accessed as a struct with two leading integers32 followed by a string. USERS: We could write a script to extract such information from C files and generate documentation. BINDINGS: On signal callback we just query Evas_Smart_Class from Evas_Object then type from it. With type we can query a hash that dispatch function for that type, converting native types to wrapped types. I don't plan to enforce checking on evas_object_smart_callback_call(), but that could be a compile/run time toggle to help spotting bugs. = Problems = - inheriting from another class would not automatically copy signals. This could be worked around with a new call "evas_smart_class_inherit_from()" that would copy all members and duplicate this array/list. - "generic" smart objects would not be able to cooperate with it. I clearly don't care much about this case as I find it abuse and not the best solution as it would make bindings nearly impossible to do efficiently. Unfortunately this is a real world case and raster likes it, current elementary is built just like that, with a single "elm_widget" class and all other widgets set hooks instead of inheriting. A possibly solution for it is to add extra pointer per Evas_Object_Smart with per-object signals. Then one could register signals per instance as well as per class. I dislike it though. = Summary = EVAS_SMART_CLASS_VERSION -> 4 (version++) struct Evas_Smart_Class: add const struct Evas_Smart_Callback { const char *name, const char *type; } *callbacks; // pseudo code: const char *evas_object_smart_callback_type_get(Evas_Object *o, const char *callback_name) { const struct Evas_Smart_Callback *cb; cb = _evas_object_smart_callback_get(o->instance_callbacks, callback_name); if (cb) return cb->type; const Evas_Smart *smart = evas_object_smart_smart_get(o); const Evas_Smart_Class *sc = evas_smart_class_get(smart); cb = _evas_object_smart_callback_get(sc->callbacks, callback_name); if (cb) return cb->type; error("no callback %s in object %p (%s) type %s\n", callback_name, o, o->name, smart->name); return NULL; } // pseudo code: Eina_Bool evas_smart_class_inherit(Evas_Smart_Class *dst, const Evas_Smart_Class *src) { if (!dst || !src) return 0; memcpy(dst, src, sizeof(Evas_Smart_Class)); dst->callbacks = _evas_smart_class_callbacks_dup(src->callbacks); return 1; } we can add variants to add extra callbacks or even provide functions to just manipulate callbacks (join, copy) and let user handle it, like: my_sc->callbacks = evas_smart_callbacks_join(parent_sc->callbacks, my_sc_extra_callbacks); = Notes = * merge: no, it's not a miracle and I don't suddenly have time to do it all, but I guess I can bootstrap it and have more people to do the conversion of remaining parts. I'll probably do the 1% of the work, but I guess it's the tricky part and rest is basically copy & paste, sed, etc. ** no deadlines yet, but I'll do my best. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Gustavo S. B. <bar...@pr...> - 2009-07-30 00:02:51
|
On Wed, Jul 29, 2009 at 7:46 PM, Gustavo Sverzut Barbieri<bar...@pr...> wrote: > Hello all, > > I'm planning to bootstrap the guarana + elementary merge* soon** but I > want to solve an unsolved problem first: help bindings and users of > evas_object_smart_callback*. > > If you're out of time to read it in detail, skip to end and read > "Summary" at least. > > = Problem = > Evas smart objects can emit signals with data, but these are > free-form. Nobody knows which signals are emitted or which type of > data they carry. This makes life of users harder since they have to > grep for code or hope that there is documentation and it's up to date, > which is quite hard we know. For bindings it's even worse, as we have > to do it and write specific mappers for each signal, that's very > boring and error prone. > > = Solution = > I would like to avoid breaking current code, so changing things > drastically is a no go. I could also propose a new system with signal > inheritance and index access to speed up dispatching and all, but I > guess the best is to build on top of existing stuff as it's "fine" for > our use cases. > > The proposal is to add an array/list of signals-types to > Evas_Smart_Class. This array would be defined when class is created > and should not be changed afterwards. Types would be DBus-like type > strings (http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-signatures), > for example "iis" is accessed as a struct with two leading integers32 > followed by a string. > > USERS: We could write a script to extract such information from C > files and generate documentation. > > BINDINGS: On signal callback we just query Evas_Smart_Class from > Evas_Object then type from it. With type we can query a hash that > dispatch function for that type, converting native types to wrapped > types. > > I don't plan to enforce checking on evas_object_smart_callback_call(), > but that could be a compile/run time toggle to help spotting bugs. > > = Problems = > - inheriting from another class would not automatically copy signals. > This could be worked around with a new call > "evas_smart_class_inherit_from()" that would copy all members and > duplicate this array/list. > > - "generic" smart objects would not be able to cooperate with it. I > clearly don't care much about this case as I find it abuse and not the > best solution as it would make bindings nearly impossible to do > efficiently. Unfortunately this is a real world case and raster likes > it, current elementary is built just like that, with a single > "elm_widget" class and all other widgets set hooks instead of > inheriting. A possibly solution for it is to add extra pointer per > Evas_Object_Smart with per-object signals. Then one could register > signals per instance as well as per class. I dislike it though. > > > > = Summary = > EVAS_SMART_CLASS_VERSION -> 4 (version++) > struct Evas_Smart_Class: add > const struct Evas_Smart_Callback { const char *name, const char > *type; } *callbacks; > > // pseudo code: > const char *evas_object_smart_callback_type_get(Evas_Object *o, const > char *callback_name) > { > const struct Evas_Smart_Callback *cb; > > cb = _evas_object_smart_callback_get(o->instance_callbacks, callback_name); > if (cb) return cb->type; > > const Evas_Smart *smart = evas_object_smart_smart_get(o); > const Evas_Smart_Class *sc = evas_smart_class_get(smart); > cb = _evas_object_smart_callback_get(sc->callbacks, callback_name); > if (cb) return cb->type; > > error("no callback %s in object %p (%s) type %s\n", callback_name, > o, o->name, smart->name); > return NULL; > } > > // pseudo code: > Eina_Bool evas_smart_class_inherit(Evas_Smart_Class *dst, const > Evas_Smart_Class *src) > { > if (!dst || !src) return 0; > memcpy(dst, src, sizeof(Evas_Smart_Class)); > dst->callbacks = _evas_smart_class_callbacks_dup(src->callbacks); > return 1; > } > > we can add variants to add extra callbacks or even provide functions > to just manipulate callbacks (join, copy) and let user handle it, > like: > my_sc->callbacks = evas_smart_callbacks_join(parent_sc->callbacks, > my_sc_extra_callbacks); I hate replying to myself, but I clearly missed an important thing here: making the Evas_Smart_Class have a pointer to parent, that way we basically solve the problem of copying callback definitions as we can walk ->parent and check it there. It will also help calling the parent methods, for example users of "clipped smart object" need to call original "del" method and to do so it need to keep the copy of the original method, this way we just sc->parent->del(o) Of course it adds a bit of overhead of walking the hierarchy, but it shouldn't matter much as it should not be that deep/long. The inherit call could also take a "size" parameter allowing extensions of Evas_Smart_Class to be inherited as well, for example: evas_smart_class_inherit(child, parent, sizeof(*parent)); maybe this size could be inside parent itself, but I see this getting out of sync easily. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Cedric B. <ced...@fr...> - 2009-07-30 09:28:57
|
Hi, On Thu, Jul 30, 2009 at 12:46 AM, Gustavo Sverzut Barbieri<bar...@pr...> wrote: > = Solution = > I would like to avoid breaking current code, so changing things > drastically is a no go. I could also propose a new system with signal > inheritance and index access to speed up dispatching and all, but I > guess the best is to build on top of existing stuff as it's "fine" for > our use cases. > > The proposal is to add an array/list of signals-types to > Evas_Smart_Class. This array would be defined when class is created > and should not be changed afterwards. Types would be DBus-like type > strings (http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-signatures), > for example "iis" is accessed as a struct with two leading integers32 > followed by a string. Hum, why not EET_DATA for that ? We have EET_DATA_DESCRIPTOR for the description. We should be able to generate from/to object script too. > USERS: We could write a script to extract such information from C > files and generate documentation. I was thinking about this using EET_DATA_DESCRIPTOR, we should be able to generate doc. Or we could do the other way around with a simplified syntax, we could generate C file that provide EET_DATA_DESCRIPTOR alongside with documentation (based on the same idea as bison, flex or gperf). This way it would be easier to use EET_DATA for more thing like network traffic (it's way faster to process eet_data than xml), IPC. What do you think about this addition to your proposal ? Note, that I like the idea you are proposing for some kind of object inheritance with evas_smart, this would bring some usefull capability to the EFL. And I would just use the ->parent mecanism for almost every thing including signal inheritence. -- Cedric BAIL |
From: Christopher M. <cpm...@co...> - 2009-07-30 10:14:04
|
Gustavo Sverzut Barbieri wrote: > Hello all, > > I'm planning to bootstrap the guarana + elementary merge* soon** but I > want to solve an unsolved problem first: help bindings and users of > evas_object_smart_callback*. > > If you're out of time to read it in detail, skip to end and read > "Summary" at least. > > = Problem = > Evas smart objects can emit signals with data, but these are > free-form. Nobody knows which signals are emitted or which type of > data they carry. This makes life of users harder since they have to > grep for code or hope that there is documentation and it's up to date, > which is quite hard we know. For bindings it's even worse, as we have > to do it and write specific mappers for each signal, that's very > boring and error prone. > > = Solution = > I would like to avoid breaking current code, so changing things > drastically is a no go. I could also propose a new system with signal > inheritance and index access to speed up dispatching and all, but I > guess the best is to build on top of existing stuff as it's "fine" for > our use cases. > > The proposal is to add an array/list of signals-types to > Evas_Smart_Class. This array would be defined when class is created > and should not be changed afterwards. Types would be DBus-like type > strings (http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-signatures), > for example "iis" is accessed as a struct with two leading integers32 > followed by a string. > > USERS: We could write a script to extract such information from C > files and generate documentation. > > BINDINGS: On signal callback we just query Evas_Smart_Class from > Evas_Object then type from it. With type we can query a hash that > dispatch function for that type, converting native types to wrapped > types. > > I don't plan to enforce checking on evas_object_smart_callback_call(), > but that could be a compile/run time toggle to help spotting bugs. > > = Problems = > - inheriting from another class would not automatically copy signals. > This could be worked around with a new call > "evas_smart_class_inherit_from()" that would copy all members and > duplicate this array/list. > > - "generic" smart objects would not be able to cooperate with it. I > clearly don't care much about this case as I find it abuse and not the > best solution as it would make bindings nearly impossible to do > efficiently. Unfortunately this is a real world case and raster likes > it, If it's not broken, why fix it ? current elementary is built just like that, with a single > "elm_widget" class and all other widgets set hooks instead of > inheriting. Nice thing about current way is that it leaves one nice clean place for tracking problems...rather than hunting down a bunch of inherit issues which may not even be E(FL)'s fault.... A possibly solution for it is to add extra pointer per > Evas_Object_Smart with per-object signals. Then one could register > signals per instance as well as per class. I dislike it though. > Agreed. Not liked too much....who/what defines the per-object ? One object is diff from another how ? The current way, everything is derived from a single "object" (elm_wid, etc) ... Is this about being "nicer" to "other languages" ? OR is there a benchmark that says "this is the better way" ?? Politely, dh > > > = Summary = > EVAS_SMART_CLASS_VERSION -> 4 (version++) > struct Evas_Smart_Class: add > const struct Evas_Smart_Callback { const char *name, const char > *type; } *callbacks; > > // pseudo code: > const char *evas_object_smart_callback_type_get(Evas_Object *o, const > char *callback_name) > { > const struct Evas_Smart_Callback *cb; > > cb = _evas_object_smart_callback_get(o->instance_callbacks, callback_name); > if (cb) return cb->type; > > const Evas_Smart *smart = evas_object_smart_smart_get(o); > const Evas_Smart_Class *sc = evas_smart_class_get(smart); > cb = _evas_object_smart_callback_get(sc->callbacks, callback_name); > if (cb) return cb->type; > > error("no callback %s in object %p (%s) type %s\n", callback_name, > o, o->name, smart->name); > return NULL; > } > > // pseudo code: > Eina_Bool evas_smart_class_inherit(Evas_Smart_Class *dst, const > Evas_Smart_Class *src) > { > if (!dst || !src) return 0; > memcpy(dst, src, sizeof(Evas_Smart_Class)); > dst->callbacks = _evas_smart_class_callbacks_dup(src->callbacks); > return 1; > } > > we can add variants to add extra callbacks or even provide functions > to just manipulate callbacks (join, copy) and let user handle it, > like: > my_sc->callbacks = evas_smart_callbacks_join(parent_sc->callbacks, > my_sc_extra_callbacks); > > > > = Notes = > * merge: no, it's not a miracle and I don't suddenly have time to do > it all, but I guess I can bootstrap it and have more people to do the > conversion of remaining parts. I'll probably do the 1% of the work, > but I guess it's the tricky part and rest is basically copy & paste, > sed, etc. > ** no deadlines yet, but I'll do my best. > |
From: Christopher M. <cpm...@co...> - 2009-07-30 10:17:39
|
Gustavo Sverzut Barbieri wrote: > On Wed, Jul 29, 2009 at 7:46 PM, Gustavo Sverzut > Barbieri<bar...@pr...> wrote: >> Hello all, >> >> I'm planning to bootstrap the guarana + elementary merge* soon** but I >> want to solve an unsolved problem first: help bindings and users of >> evas_object_smart_callback*. >> >> If you're out of time to read it in detail, skip to end and read >> "Summary" at least. >> >> = Problem = >> Evas smart objects can emit signals with data, but these are >> free-form. Nobody knows which signals are emitted or which type of >> data they carry. This makes life of users harder since they have to >> grep for code or hope that there is documentation and it's up to date, >> which is quite hard we know. For bindings it's even worse, as we have >> to do it and write specific mappers for each signal, that's very >> boring and error prone. >> >> = Solution = >> I would like to avoid breaking current code, so changing things >> drastically is a no go. I could also propose a new system with signal >> inheritance and index access to speed up dispatching and all, but I >> guess the best is to build on top of existing stuff as it's "fine" for >> our use cases. >> >> The proposal is to add an array/list of signals-types to >> Evas_Smart_Class. This array would be defined when class is created >> and should not be changed afterwards. Types would be DBus-like type >> strings (http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-signatures), >> for example "iis" is accessed as a struct with two leading integers32 >> followed by a string. >> >> USERS: We could write a script to extract such information from C >> files and generate documentation. >> >> BINDINGS: On signal callback we just query Evas_Smart_Class from >> Evas_Object then type from it. With type we can query a hash that >> dispatch function for that type, converting native types to wrapped >> types. >> >> I don't plan to enforce checking on evas_object_smart_callback_call(), >> but that could be a compile/run time toggle to help spotting bugs. >> >> = Problems = >> - inheriting from another class would not automatically copy signals. >> This could be worked around with a new call >> "evas_smart_class_inherit_from()" that would copy all members and >> duplicate this array/list. >> >> - "generic" smart objects would not be able to cooperate with it. I >> clearly don't care much about this case as I find it abuse and not the >> best solution as it would make bindings nearly impossible to do >> efficiently. Unfortunately this is a real world case and raster likes >> it, current elementary is built just like that, with a single >> "elm_widget" class and all other widgets set hooks instead of >> inheriting. A possibly solution for it is to add extra pointer per >> Evas_Object_Smart with per-object signals. Then one could register >> signals per instance as well as per class. I dislike it though. >> >> >> >> = Summary = >> EVAS_SMART_CLASS_VERSION -> 4 (version++) >> struct Evas_Smart_Class: add >> const struct Evas_Smart_Callback { const char *name, const char >> *type; } *callbacks; >> >> // pseudo code: >> const char *evas_object_smart_callback_type_get(Evas_Object *o, const >> char *callback_name) >> { >> const struct Evas_Smart_Callback *cb; >> >> cb = _evas_object_smart_callback_get(o->instance_callbacks, callback_name); >> if (cb) return cb->type; >> >> const Evas_Smart *smart = evas_object_smart_smart_get(o); >> const Evas_Smart_Class *sc = evas_smart_class_get(smart); >> cb = _evas_object_smart_callback_get(sc->callbacks, callback_name); >> if (cb) return cb->type; >> >> error("no callback %s in object %p (%s) type %s\n", callback_name, >> o, o->name, smart->name); >> return NULL; >> } >> >> // pseudo code: >> Eina_Bool evas_smart_class_inherit(Evas_Smart_Class *dst, const >> Evas_Smart_Class *src) >> { >> if (!dst || !src) return 0; >> memcpy(dst, src, sizeof(Evas_Smart_Class)); >> dst->callbacks = _evas_smart_class_callbacks_dup(src->callbacks); >> return 1; >> } >> >> we can add variants to add extra callbacks or even provide functions >> to just manipulate callbacks (join, copy) and let user handle it, >> like: >> my_sc->callbacks = evas_smart_callbacks_join(parent_sc->callbacks, >> my_sc_extra_callbacks); > > I hate replying to myself, but I clearly missed an important thing > here: making the Evas_Smart_Class have a pointer to parent, that way > we basically solve the problem of copying callback definitions as we > can walk ->parent and check it there. It will also help calling the > parent methods, for example users of "clipped smart object" need to > call original "del" method and to do so it need to keep the copy of > the original method, this way we just sc->parent->del(o) > > Of course it adds a bit of overhead of walking the hierarchy, but it > shouldn't matter much as it should not be that deep/long. > "Should" being the operative word !! What's to stop someone from overloading ??? > The inherit call could also take a "size" parameter allowing > extensions of Evas_Smart_Class to be inherited as well, for example: > > evas_smart_class_inherit(child, parent, sizeof(*parent)); > > maybe this size could be inside parent itself, but I see this getting > out of sync easily. > Indeed. dh |
From: Gustavo S. B. <bar...@pr...> - 2009-07-30 12:11:14
|
On Thu, Jul 30, 2009 at 7:17 AM, Christopher Michael<cpm...@co...> wrote: > Gustavo Sverzut Barbieri wrote: >> I hate replying to myself, but I clearly missed an important thing >> here: making the Evas_Smart_Class have a pointer to parent, that way >> we basically solve the problem of copying callback definitions as we >> can walk ->parent and check it there. It will also help calling the >> parent methods, for example users of "clipped smart object" need to >> call original "del" method and to do so it need to keep the copy of >> the original method, this way we just sc->parent->del(o) >> >> Of course it adds a bit of overhead of walking the hierarchy, but it >> shouldn't matter much as it should not be that deep/long. >> > > "Should" being the operative word !! What's to stop someone from overloading > ??? you mean: people can get crazy and suddenly come with 1000 levels of inheritance? Well I guess even 1000 is not that much of impact, but supposing it is, we can just recommend doing something else. And we can cache chose in Evas_Smart creation (evas_smart_new()), providing a copy of all signals merged + sorted to speed up access using binary search. But this can easily happen in other ways, for example if you add thousand objects to a single layer, things will get slower, you have to live with it :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Gustavo S. B. <bar...@pr...> - 2009-07-30 11:58:27
|
On Thu, Jul 30, 2009 at 6:28 AM, Cedric BAIL<ced...@fr...> wrote: > Hi, > > On Thu, Jul 30, 2009 at 12:46 AM, Gustavo Sverzut > Barbieri<bar...@pr...> wrote: >> = Solution = >> I would like to avoid breaking current code, so changing things >> drastically is a no go. I could also propose a new system with signal >> inheritance and index access to speed up dispatching and all, but I >> guess the best is to build on top of existing stuff as it's "fine" for >> our use cases. >> >> The proposal is to add an array/list of signals-types to >> Evas_Smart_Class. This array would be defined when class is created >> and should not be changed afterwards. Types would be DBus-like type >> strings (http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-signatures), >> for example "iis" is accessed as a struct with two leading integers32 >> followed by a string. > > Hum, why not EET_DATA for that ? We have EET_DATA_DESCRIPTOR for the > description. We should be able to generate from/to object script too. > >> USERS: We could write a script to extract such information from C >> files and generate documentation. > > I was thinking about this using EET_DATA_DESCRIPTOR, we should be able > to generate doc. Or we could do the other way around with a simplified > syntax, we could generate C file that provide EET_DATA_DESCRIPTOR > alongside with documentation (based on the same idea as bison, flex or > gperf). > > This way it would be easier to use EET_DATA for more thing like > network traffic (it's way faster to process eet_data than xml), IPC. > > What do you think about this addition to your proposal ? > > Note, that I like the idea you are proposing for some kind of object > inheritance with evas_smart, this would bring some usefull capability > to the EFL. And I would just use the ->parent mecanism for almost > every thing including signal inheritence. Regarding EET_DATA, I did think about it as well, but I like the string types more for some reasons: - simpler to use inside evas, it's just a string. and unless we want to do debugging checks, we don't need to use it in fast paths so performance is not an issue here - simpler to use by scripts, just iterate a string and output list items. - simpler to use by bindings, EET_DATA is useless for Python, for example. I would like to use write some "common dispatchers" like _evas_smart_callback_dispatch_iis() and do the generic just if required, later. To do so with strings I just need to add a hash table. All in all they're almost the same thing and the result would be the same, but i think it's easier to do so using strings... I can see this getting cumbersome to create eet_data_descriptors and all for every single signal one may emit... My proposal lacks a "name" entry for each value, which EET_DATA provides... do you think it is important to be inside code? On one hand it would be good to have this information, but on the other it would make declaration more complex and parsing harder, if we keep these 2 separate (to make parsing simpler) we can easily get out of sync. Maybe a format like TYPE:NAME,TYPE:NAME.... like "i:old_value,i:new_value" would do, then in Evas_Smart we can split and keep just the types... Evas_Smart could contain other pre-processed data, such as sorted version of all known callback names inherited. This would enable instances to speed up signal dispatching. Instead of a single list with (callback_name, func, data) we would have an array/hash of (func,data) lists and could do binary search on it for quick finding the correct list of functions for that callback name. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Gustavo S. B. <bar...@pr...> - 2009-07-30 12:08:00
|
On Thu, Jul 30, 2009 at 7:14 AM, Christopher Michael<cpm...@co...> wrote: > Gustavo Sverzut Barbieri wrote: >> >> Hello all, >> >> I'm planning to bootstrap the guarana + elementary merge* soon** but I >> want to solve an unsolved problem first: help bindings and users of >> evas_object_smart_callback*. >> >> If you're out of time to read it in detail, skip to end and read >> "Summary" at least. >> >> = Problem = >> Evas smart objects can emit signals with data, but these are >> free-form. Nobody knows which signals are emitted or which type of >> data they carry. This makes life of users harder since they have to >> grep for code or hope that there is documentation and it's up to date, >> which is quite hard we know. For bindings it's even worse, as we have >> to do it and write specific mappers for each signal, that's very >> boring and error prone. >> >> = Solution = >> I would like to avoid breaking current code, so changing things >> drastically is a no go. I could also propose a new system with signal >> inheritance and index access to speed up dispatching and all, but I >> guess the best is to build on top of existing stuff as it's "fine" for >> our use cases. >> >> The proposal is to add an array/list of signals-types to >> Evas_Smart_Class. This array would be defined when class is created >> and should not be changed afterwards. Types would be DBus-like type >> strings >> (http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-signatures), >> for example "iis" is accessed as a struct with two leading integers32 >> followed by a string. >> >> USERS: We could write a script to extract such information from C >> files and generate documentation. >> >> BINDINGS: On signal callback we just query Evas_Smart_Class from >> Evas_Object then type from it. With type we can query a hash that >> dispatch function for that type, converting native types to wrapped >> types. >> >> I don't plan to enforce checking on evas_object_smart_callback_call(), >> but that could be a compile/run time toggle to help spotting bugs. >> >> = Problems = >> - inheriting from another class would not automatically copy signals. >> This could be worked around with a new call >> "evas_smart_class_inherit_from()" that would copy all members and >> duplicate this array/list. >> >> - "generic" smart objects would not be able to cooperate with it. I >> clearly don't care much about this case as I find it abuse and not the >> best solution as it would make bindings nearly impossible to do >> efficiently. Unfortunately this is a real world case and raster likes >> it, > > If it's not broken, why fix it ? > > current elementary is built just like that, with a single >> >> "elm_widget" class and all other widgets set hooks instead of >> inheriting. > > Nice thing about current way is that it leaves one nice clean place for > tracking problems...rather than hunting down a bunch of inherit issues which > may not even be E(FL)'s fault.... It doesn't matter much where to track problems and having a single "elm_widget" makes debugging harder (which object is this? evas_object_type_get() does not help, elm_widget_type_get() could help but you'd have to know if it's an elm_widget before...) elm_widget is definitely easier to get working faster, it's simple to start... but it have its maintenance costs and don't scale that well. Raster used it to write first version since he had to create it all in short time, and even he agrees that the other solution could be better. However, we both want to provide a similar way to help doing prototypes and quick tests, that's why I'm proposing a solution for it as well. > A possibly solution for it is to add extra pointer per >> >> Evas_Object_Smart with per-object signals. Then one could register >> signals per instance as well as per class. I dislike it though. >> > Agreed. Not liked too much....who/what defines the per-object ? One object > is diff from another how ? The current way, everything is derived from a > single "object" (elm_wid, etc) ... > > Is this about being "nicer" to "other languages" ? OR is there a benchmark > that says "this is the better way" ?? This is all meta-information, by default it will not touch any fast path we use in Evas, so no impact on benchmarks. We could do more if we want, I want to have debug options to: - evas_object_smart_callback_add(): check if callback exists and print out a warning if not. - evas_object_smart_callback_call(): check if callback exists and print out a warning if not, could optionally "touch" the data accordingly to description in order to trigger memory access problems so valgrind would catch these during development. As I said to cedric in a later mail, we could cache some stuff in Evas_Smart during evas_smart_new() using merge+sort of all callbacks so calling is cheaper as we don't need to go through a list of mixed callback to possibly find none to dispatch. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Christopher M. <cpm...@co...> - 2009-07-30 16:49:46
|
Gustavo Sverzut Barbieri wrote: > On Thu, Jul 30, 2009 at 7:14 AM, Christopher > Michael<cpm...@co...> wrote: >> Gustavo Sverzut Barbieri wrote: >>> Hello all, >>> >>> I'm planning to bootstrap the guarana + elementary merge* soon** but I >>> want to solve an unsolved problem first: help bindings and users of >>> evas_object_smart_callback*. >>> >>> If you're out of time to read it in detail, skip to end and read >>> "Summary" at least. >>> >>> = Problem = >>> Evas smart objects can emit signals with data, but these are >>> free-form. Nobody knows which signals are emitted or which type of >>> data they carry. This makes life of users harder since they have to >>> grep for code or hope that there is documentation and it's up to date, >>> which is quite hard we know. For bindings it's even worse, as we have >>> to do it and write specific mappers for each signal, that's very >>> boring and error prone. >>> >>> = Solution = >>> I would like to avoid breaking current code, so changing things >>> drastically is a no go. I could also propose a new system with signal >>> inheritance and index access to speed up dispatching and all, but I >>> guess the best is to build on top of existing stuff as it's "fine" for >>> our use cases. >>> >>> The proposal is to add an array/list of signals-types to >>> Evas_Smart_Class. This array would be defined when class is created >>> and should not be changed afterwards. Types would be DBus-like type >>> strings >>> (http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-signatures), >>> for example "iis" is accessed as a struct with two leading integers32 >>> followed by a string. >>> >>> USERS: We could write a script to extract such information from C >>> files and generate documentation. >>> >>> BINDINGS: On signal callback we just query Evas_Smart_Class from >>> Evas_Object then type from it. With type we can query a hash that >>> dispatch function for that type, converting native types to wrapped >>> types. >>> >>> I don't plan to enforce checking on evas_object_smart_callback_call(), >>> but that could be a compile/run time toggle to help spotting bugs. >>> >>> = Problems = >>> - inheriting from another class would not automatically copy signals. >>> This could be worked around with a new call >>> "evas_smart_class_inherit_from()" that would copy all members and >>> duplicate this array/list. >>> >>> - "generic" smart objects would not be able to cooperate with it. I >>> clearly don't care much about this case as I find it abuse and not the >>> best solution as it would make bindings nearly impossible to do >>> efficiently. Unfortunately this is a real world case and raster likes >>> it, >> If it's not broken, why fix it ? >> >> current elementary is built just like that, with a single >>> "elm_widget" class and all other widgets set hooks instead of >>> inheriting. >> Nice thing about current way is that it leaves one nice clean place for >> tracking problems...rather than hunting down a bunch of inherit issues which >> may not even be E(FL)'s fault.... > > It doesn't matter much where to track problems and having a single > "elm_widget" makes debugging harder (which object is this? > evas_object_type_get() does not help, elm_widget_type_get() could help > but you'd have to know if it's an elm_widget before...) > > elm_widget is definitely easier to get working faster, it's simple to > start... but it have its maintenance costs and don't scale that well. > Raster used it to write first version since he had to create it all in > short time, and even he agrees that the other solution could be > better. However, we both want to provide a similar way to help doing > prototypes and quick tests, that's why I'm proposing a solution for it > as well. > > >> A possibly solution for it is to add extra pointer per >>> Evas_Object_Smart with per-object signals. Then one could register >>> signals per instance as well as per class. I dislike it though. >>> >> Agreed. Not liked too much....who/what defines the per-object ? One object >> is diff from another how ? The current way, everything is derived from a >> single "object" (elm_wid, etc) ... >> >> Is this about being "nicer" to "other languages" ? OR is there a benchmark >> that says "this is the better way" ?? > > This is all meta-information, by default it will not touch any fast > path we use in Evas, so no impact on benchmarks. > > We could do more if we want, I want to have debug options to: > - evas_object_smart_callback_add(): check if callback exists and > print out a warning if not. > - evas_object_smart_callback_call(): check if callback exists and > print out a warning if not, could optionally "touch" the data > accordingly to description in order to trigger memory access problems > so valgrind would catch these during development. > > As I said to cedric in a later mail, we could cache some stuff in > Evas_Smart during evas_smart_new() using merge+sort of all callbacks > so calling is cheaper as we don't need to go through a list of mixed > callback to possibly find none to dispatch. > Valid points which make sense...I say go for it dh |
From: Cedric B. <ced...@fr...> - 2009-07-30 12:21:24
|
On Thu, Jul 30, 2009 at 1:58 PM, Gustavo Sverzut Barbieri<bar...@pr...> wrote: > On Thu, Jul 30, 2009 at 6:28 AM, Cedric BAIL<ced...@fr...> wrote: >> Hi, >> >> On Thu, Jul 30, 2009 at 12:46 AM, Gustavo Sverzut >> Barbieri<bar...@pr...> wrote: >>> = Solution = >>> I would like to avoid breaking current code, so changing things >>> drastically is a no go. I could also propose a new system with signal >>> inheritance and index access to speed up dispatching and all, but I >>> guess the best is to build on top of existing stuff as it's "fine" for >>> our use cases. >>> >>> The proposal is to add an array/list of signals-types to >>> Evas_Smart_Class. This array would be defined when class is created >>> and should not be changed afterwards. Types would be DBus-like type >>> strings (http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-signatures), >>> for example "iis" is accessed as a struct with two leading integers32 >>> followed by a string. >> >> Hum, why not EET_DATA for that ? We have EET_DATA_DESCRIPTOR for the >> description. We should be able to generate from/to object script too. >> >>> USERS: We could write a script to extract such information from C >>> files and generate documentation. >> >> I was thinking about this using EET_DATA_DESCRIPTOR, we should be able >> to generate doc. Or we could do the other way around with a simplified >> syntax, we could generate C file that provide EET_DATA_DESCRIPTOR >> alongside with documentation (based on the same idea as bison, flex or >> gperf). >> >> This way it would be easier to use EET_DATA for more thing like >> network traffic (it's way faster to process eet_data than xml), IPC. >> >> What do you think about this addition to your proposal ? >> >> Note, that I like the idea you are proposing for some kind of object >> inheritance with evas_smart, this would bring some usefull capability >> to the EFL. And I would just use the ->parent mecanism for almost >> every thing including signal inheritence. > > > Regarding EET_DATA, I did think about it as well, but I like the > string types more for some reasons: > - simpler to use inside evas, it's just a string. and unless we > want to do debugging checks, we don't need to use it in fast paths so > performance is not an issue here > - simpler to use by scripts, just iterate a string and output list items. > - simpler to use by bindings, EET_DATA is useless for Python, for > example. I would like to use write some "common dispatchers" like > _evas_smart_callback_dispatch_iis() and do the generic just if > required, later. To do so with strings I just need to add a hash > table. Hum, I would have say an array, as we don't have key name in front of the value. Beside that, I know that currently, their is no easy way to generate an Eet_Node tree from an Eet_Data structure. This limite the automatic transformation from Eet_Data to Script object. But as I already did the other way around from Eet_Node to Eet_Data (meaning it is possible to generate Eet_Data from a Python object quite easily now), I plan to do this shortly as I need it (And it will clean Eet_Data internal in the mean time). So at some point, it will not be that much useless to have an Eet_Data/Python Object converter. > All in all they're almost the same thing and the result would be the > same, but i think it's easier to do so using strings... I can see this > getting cumbersome to create eet_data_descriptors and all for every > single signal one may emit... Yep, definitively. > My proposal lacks a "name" entry for each value, which EET_DATA > provides... do you think it is important to be inside code? On one > hand it would be good to have this information, but on the other it > would make declaration more complex and parsing harder, if we keep > these 2 separate (to make parsing simpler) we can easily get out of > sync. Maybe a format like TYPE:NAME,TYPE:NAME.... like > "i:old_value,i:new_value" would do, then in Evas_Smart we can split > and keep just the types... That was my reason behind eet, having the possibility to name each chunk easily and with some meaning (it would ease the creation of binding, as we will have real object with propertie name). So yes, I like name, but I don't like the idea of a new "protocol" to parse. So I will disagree on putting a complex scheme like that. Or we ease EET_DATA use, with some tool that generate EET_DATA_DESCRIPTOR, or we go to the easy and small path of your first proposal. I prefer EET_DATA as it's really easy to use in C, and will be for script to. We just need an way to represent it in our documentation. The drawback is that it would make Eet a strong dependency for Evas, not a big deal in my opinion. > Evas_Smart could contain other pre-processed data, such as sorted > version of all known callback names inherited. This would enable > instances to speed up signal dispatching. Instead of a single list > with (callback_name, func, data) we would have an array/hash of > (func,data) lists and could do binary search on it for quick finding > the correct list of functions for that callback name. A small hash table will do the trick and be fast enough, without consuming too much memory (as it is shared by all object from the same type if I understood correctly). -- Cedric BAIL |
From: Gustavo S. B. <bar...@pr...> - 2009-07-30 12:35:18
|
On Thu, Jul 30, 2009 at 9:20 AM, Cedric BAIL<ced...@fr...> wrote: > On Thu, Jul 30, 2009 at 1:58 PM, Gustavo Sverzut > Barbieri<bar...@pr...> wrote: >> On Thu, Jul 30, 2009 at 6:28 AM, Cedric BAIL<ced...@fr...> wrote: >>> Hi, >>> >>> On Thu, Jul 30, 2009 at 12:46 AM, Gustavo Sverzut >>> Barbieri<bar...@pr...> wrote: >>>> = Solution = >>>> I would like to avoid breaking current code, so changing things >>>> drastically is a no go. I could also propose a new system with signal >>>> inheritance and index access to speed up dispatching and all, but I >>>> guess the best is to build on top of existing stuff as it's "fine" for >>>> our use cases. >>>> >>>> The proposal is to add an array/list of signals-types to >>>> Evas_Smart_Class. This array would be defined when class is created >>>> and should not be changed afterwards. Types would be DBus-like type >>>> strings (http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-signatures), >>>> for example "iis" is accessed as a struct with two leading integers32 >>>> followed by a string. >>> >>> Hum, why not EET_DATA for that ? We have EET_DATA_DESCRIPTOR for the >>> description. We should be able to generate from/to object script too. >>> >>>> USERS: We could write a script to extract such information from C >>>> files and generate documentation. >>> >>> I was thinking about this using EET_DATA_DESCRIPTOR, we should be able >>> to generate doc. Or we could do the other way around with a simplified >>> syntax, we could generate C file that provide EET_DATA_DESCRIPTOR >>> alongside with documentation (based on the same idea as bison, flex or >>> gperf). >>> >>> This way it would be easier to use EET_DATA for more thing like >>> network traffic (it's way faster to process eet_data than xml), IPC. >>> >>> What do you think about this addition to your proposal ? >>> >>> Note, that I like the idea you are proposing for some kind of object >>> inheritance with evas_smart, this would bring some usefull capability >>> to the EFL. And I would just use the ->parent mecanism for almost >>> every thing including signal inheritence. >> >> >> Regarding EET_DATA, I did think about it as well, but I like the >> string types more for some reasons: >> - simpler to use inside evas, it's just a string. and unless we >> want to do debugging checks, we don't need to use it in fast paths so >> performance is not an issue here >> - simpler to use by scripts, just iterate a string and output list items. >> - simpler to use by bindings, EET_DATA is useless for Python, for >> example. I would like to use write some "common dispatchers" like >> _evas_smart_callback_dispatch_iis() and do the generic just if >> required, later. To do so with strings I just need to add a hash >> table. > > Hum, I would have say an array, as we don't have key name in front of > the value. Beside that, I know that currently, their is no easy way to > generate an Eet_Node tree from an Eet_Data structure. This limite the > automatic transformation from Eet_Data to Script object. But as I > already did the other way around from Eet_Node to Eet_Data (meaning it > is possible to generate Eet_Data from a Python object quite easily > now), I plan to do this shortly as I need it (And it will clean > Eet_Data internal in the mean time). So at some point, it will not be > that much useless to have an Eet_Data/Python Object converter. > >> All in all they're almost the same thing and the result would be the >> same, but i think it's easier to do so using strings... I can see this >> getting cumbersome to create eet_data_descriptors and all for every >> single signal one may emit... > > Yep, definitively. > >> My proposal lacks a "name" entry for each value, which EET_DATA >> provides... do you think it is important to be inside code? On one >> hand it would be good to have this information, but on the other it >> would make declaration more complex and parsing harder, if we keep >> these 2 separate (to make parsing simpler) we can easily get out of >> sync. Maybe a format like TYPE:NAME,TYPE:NAME.... like >> "i:old_value,i:new_value" would do, then in Evas_Smart we can split >> and keep just the types... > > That was my reason behind eet, having the possibility to name each > chunk easily and with some meaning (it would ease the creation of > binding, as we will have real object with propertie name). So yes, I > like name, but I don't like the idea of a new "protocol" to parse. So > I will disagree on putting a complex scheme like that. Or we ease > EET_DATA use, with some tool that generate EET_DATA_DESCRIPTOR, or we > go to the easy and small path of your first proposal. I prefer > EET_DATA as it's really easy to use in C, and will be for script to. > We just need an way to represent it in our documentation. Hum, I dislike having to provide another file that generates another one that is included by every class. We'll basically double the number of files in Elementary, or triple if if you consider the generated. But on the other hand this is technically good and if description is simple, like Edje, we can even include it verbatim in documentation, like: callbacks { callback { name: "value-changed"; value: INT "old"; value: INT "new"; } } But again, it's getting too complex and I'd like to avoid if if possible. > The drawback is that it would make Eet a strong dependency for Evas, > not a big deal in my opinion. this is not an issue, we can split descriptors out of eet, maybe move it to eina or a new lib. >> Evas_Smart could contain other pre-processed data, such as sorted >> version of all known callback names inherited. This would enable >> instances to speed up signal dispatching. Instead of a single list >> with (callback_name, func, data) we would have an array/hash of >> (func,data) lists and could do binary search on it for quick finding >> the correct list of functions for that callback name. > > A small hash table will do the trick and be fast enough, without > consuming too much memory (as it is shared by all object from the same > type if I understood correctly). No, this is per instance object as it's the connections of that instance. But it can be created/destroyed on demand and if we create a small/regular hash we could know from number of know signals (of class, the instance defined signals to help elm_widget are another issue). -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: Carsten H. (T. R. <ra...@ra...> - 2009-09-04 16:04:38
|
On Wed, 29 Jul 2009 19:46:20 -0300 Gustavo Sverzut Barbieri <bar...@pr...> said: overall i like the idea. it's a more structured way to have arbitrary smart callback signal names. it's runtime discoverable. while we're at it... it means the strings are in an array/table. they should be stringshared. imho this means that the class either should declare them with eina_stringshare - or a function that takes and array of strings will stringshare each into an internal array. then we can use if (x == y) instead of if (!strcmp(x, y)) (in fact i just changed in svn evas_object_smart_callback_call() to create a temporary stringshare of the event string to turn the compare into a ==) as for format string of the event_info. i see no reason why not. sometimes it's opaque though. ie an object handle. need a way to be able to specify that too. > Hello all, > > I'm planning to bootstrap the guarana + elementary merge* soon** but I > want to solve an unsolved problem first: help bindings and users of > evas_object_smart_callback*. > > If you're out of time to read it in detail, skip to end and read > "Summary" at least. > > = Problem = > Evas smart objects can emit signals with data, but these are > free-form. Nobody knows which signals are emitted or which type of > data they carry. This makes life of users harder since they have to > grep for code or hope that there is documentation and it's up to date, > which is quite hard we know. For bindings it's even worse, as we have > to do it and write specific mappers for each signal, that's very > boring and error prone. > > = Solution = > I would like to avoid breaking current code, so changing things > drastically is a no go. I could also propose a new system with signal > inheritance and index access to speed up dispatching and all, but I > guess the best is to build on top of existing stuff as it's "fine" for > our use cases. > > The proposal is to add an array/list of signals-types to > Evas_Smart_Class. This array would be defined when class is created > and should not be changed afterwards. Types would be DBus-like type > strings > (http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-signatures), > for example "iis" is accessed as a struct with two leading integers32 > followed by a string. > > USERS: We could write a script to extract such information from C > files and generate documentation. > > BINDINGS: On signal callback we just query Evas_Smart_Class from > Evas_Object then type from it. With type we can query a hash that > dispatch function for that type, converting native types to wrapped > types. > > I don't plan to enforce checking on evas_object_smart_callback_call(), > but that could be a compile/run time toggle to help spotting bugs. > > = Problems = > - inheriting from another class would not automatically copy signals. > This could be worked around with a new call > "evas_smart_class_inherit_from()" that would copy all members and > duplicate this array/list. > > - "generic" smart objects would not be able to cooperate with it. I > clearly don't care much about this case as I find it abuse and not the > best solution as it would make bindings nearly impossible to do > efficiently. Unfortunately this is a real world case and raster likes > it, current elementary is built just like that, with a single > "elm_widget" class and all other widgets set hooks instead of > inheriting. A possibly solution for it is to add extra pointer per > Evas_Object_Smart with per-object signals. Then one could register > signals per instance as well as per class. I dislike it though. > > > > = Summary = > EVAS_SMART_CLASS_VERSION -> 4 (version++) > struct Evas_Smart_Class: add > const struct Evas_Smart_Callback { const char *name, const char > *type; } *callbacks; > > // pseudo code: > const char *evas_object_smart_callback_type_get(Evas_Object *o, const > char *callback_name) > { > const struct Evas_Smart_Callback *cb; > > cb = _evas_object_smart_callback_get(o->instance_callbacks, > callback_name); if (cb) return cb->type; > > const Evas_Smart *smart = evas_object_smart_smart_get(o); > const Evas_Smart_Class *sc = evas_smart_class_get(smart); > cb = _evas_object_smart_callback_get(sc->callbacks, callback_name); > if (cb) return cb->type; > > error("no callback %s in object %p (%s) type %s\n", callback_name, > o, o->name, smart->name); > return NULL; > } > > // pseudo code: > Eina_Bool evas_smart_class_inherit(Evas_Smart_Class *dst, const > Evas_Smart_Class *src) > { > if (!dst || !src) return 0; > memcpy(dst, src, sizeof(Evas_Smart_Class)); > dst->callbacks = _evas_smart_class_callbacks_dup(src->callbacks); > return 1; > } > > we can add variants to add extra callbacks or even provide functions > to just manipulate callbacks (join, copy) and let user handle it, > like: > my_sc->callbacks = evas_smart_callbacks_join(parent_sc->callbacks, > my_sc_extra_callbacks); > > > > = Notes = > * merge: no, it's not a miracle and I don't suddenly have time to do > it all, but I guess I can bootstrap it and have more people to do the > conversion of remaining parts. I'll probably do the 1% of the work, > but I guess it's the tricky part and rest is basically copy & paste, > sed, etc. > ** no deadlines yet, but I'll do my best. > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: bar...@gm... > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Gustavo S. B. <bar...@pr...> - 2009-09-04 20:14:00
|
On Thu, Sep 3, 2009 at 9:45 PM, Carsten Haitzler<ra...@ra...> wrote: > On Wed, 29 Jul 2009 19:46:20 -0300 Gustavo Sverzut Barbieri > <bar...@pr...> said: > > overall i like the idea. it's a more structured way to have arbitrary smart > callback signal names. it's runtime discoverable. while we're at it... I have it written already, just needs testing. Sachiel and I were starting to test it, but then we ran into other stuff and then snapshot came and I rather focus on eina than it. As my patch also covers inheritance with Evas_Smart_Class->parent I thought some things would work but I overlooked and I'll have to remove some code and add some glib-like macros (like G_DEFINE_TYPE()) to help declare smart classes and call parent class stuff. > it means > the strings are in an array/table. they should be stringshared. imho this means > that the class either should declare them with eina_stringshare - or a function > that takes and array of strings will stringshare each into an internal array. > then we can use > > if (x == y) > > instead of > > if (!strcmp(x, y)) > > (in fact i just changed in svn evas_object_smart_callback_call() to create a > temporary stringshare of the event string to turn the compare into a ==) I saw your commit and realized that quickly. I have another suggestion/approach to speed it a bit more. Since we can know beforehand the class/instance signals, on the first connection we can create an array of that size. This array would contain buckets with [name, list-of-connections], since I keep names sorted already, we can do binary search on it. It's no pointer comparison, but on the other hand we don't have to walk a list of all signals, we cut straight to the chase and dispatch all signals once we find their buckets. Of course we need 2 special cases: - no signal connections has no array, so just ignore. fast and saves memory. - signals connections of unregistered name: warn but add them to another bucket that will be looked once it's not found in named buckets. This one would behave like current approach and can be optimized with stringshare, but I'd say it will be a not so common case that do not worth. In my implementation all strings are references to those given in Evas_Smart_Class->callbacks array, so I use pointer comparison if users want to make it fast by having global pointers that are shared (let's say, by an EAPI const char *variable) > as for format string of the event_info. i see no reason why not. sometimes it's > opaque though. ie an object handle. need a way to be able to specify that too. yes, they're just hints. However we could have a high level type "o" that is an Evas_Object. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |