Gustavo Sverzut Barbieri wrote: > On Wed, Jul 29, 2009 at 7:46 PM, Gustavo Sverzut > Barbieri<[email protected]> 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 ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
