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