Hello, I've been working on a different (and more flexible) design for the List widget. The code is changing as I implement things, but a basic design settled down. The idea is if this new design works better, we can try port the Tree widget too (so List will be just a subcase).
The code is in: http://staff.get-e.org/?p=users/cmarcelo/etk.git;a=shortlog;h=experimental and a very crappy example is at: http://pastie.caboo.se/private/fy4wvwfqgvsfgr7nhnyu0w For some context, enhancement reports in ETK Google Code could be helpful: http://code.google.com/p/etoolkit/issues/detail?id=37 http://code.google.com/p/etoolkit/issues/detail?id=36 I would be glad if Etk developers could take a look at this code. Follows some notes and ideas. * I want to abstract out the kinetic stuff. At first I thought it would be easier to let scrolled_view be kinetic. The way it is, List itself implement kinetics (so it can control when it's a click and when it's not). Math and code for this can be separated: having a struct with kinetic info, and calling kinetic functions to tell about mouse down/up/move events, and it would have a callback telling how much scroll. However, ideas on how to, in Evas, make the kinetic just be used by scrolled_view and components inside it magically work, I would want to hear to. Basically: we need to put a invisible object on top of the scrolled_view contents, trigger kinetic behaviour, and "inject" *some* of these events to the contents. * It may be a good idea to separate some "embedded" specific things from the main implementation. Something like having a BaseList from which both List and KineticList (or TouchscreenList) would inherit. Scrollbar behavior for Kinetic would be different, for example. * I did a "minimal" Etk_Base (less than described by bug 37 at google code) but it seems to be a good fit for now, no need for a parent for Etk_Type too. Actually I dislike the name Etk_Base, I think it should be called Etk_Object, but it would cause much noise in the changes and could make things harder. * Etk_Value (which is just a Etk_Base wrapper for simple types) fills the same "niche" of Etk_Property_Value. For bindings Etk_Base data is a uniform way to get data, making thinks easier, I think Property_Value should merge into Etk_Value, but I'm not very familiar with Property subsystem yet to say how. * Many List features are not there yet (column headers, etc). I'm focusing in get the overall structure right. * Model could be more flexible if instead of having to pass a subclass of Etk_List_Model, we pass a data pointer and a set of basic functions that the Etk_List could use to get the data. This way it will be easier to use your data in any format you like in the List. Cheers, Caio Marcelo ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
