On Thu, Jul 30, 2009 at 7:14 AM, Christopher Michael<cpmicha...@comcast.net> 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: 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
