On 9/10/07, Simon TRENY <[EMAIL PROTECTED]> wrote: > > So indeed, Ewl can handle a high number of widgets a lot more > efficiently than Etk. But that's only because it HAS to!
That's just completely wrong. We certainly could take the same approach that ETK does and use specialized handlers for each column type, but we consider it a poor API choice. There is nothing inherent in EWL that requires the rows to be a widget. The idea with tree2 is that we maintain the widget abstraction for providers to avoid additional reference to drawing engine specific objects. So as we abstract more into the engine code, we can maintain fewer references to evas specifics and ease the porting effort. We are currently in the design debugging phase of this effort, and not the optimization phase. Once we have the common code to a point we're happy with, then we will optimize for the fixed row height case (which is what ETK uses), and we only need to maintain widgets for the visible rows, just like ETK only has to maintain evas objects for those rows. We can still support variable height rows when they are useful but default to the fixed height case. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
