Gustavo Sverzut Barbieri wrote: > On Thu, Jul 30, 2009 at 7:14 AM, Christopher > Michael<[email protected]> 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 ------------------------------------------------------------------------------ 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
