[haiku-commits] Re: r38185 - haiku/trunk/src/preferences/shortcuts/clv
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Tue, 17 Aug 2010 20:45:20 +0200
On 2010-08-17 at 19:06:06 [+0200], Stephan Assmus <superstippi@xxxxxx>
wrote:
> Am 17.08.2010 17:11, schrieb Stefano Ceccherini:
> > 2010/8/17 Axel Dörfler<axeld@xxxxxxxxxxxxxxxx>:
> >
> >> I'd say we should get rid of both, actually, and port the code over to
> >> a new one that is properly designed :-)
>
> Ingo designed one once for eXposer. AFAIK, he didn't consider it
> complete/finished. I am using it in my WonderBrush rewrite, which I've
> picked up recently, and have extended it (drag&drop interface) and fixed
> some bugs. I may have not extended it in the way which Ingo envisioned.
> It has an optional model class and default implementation. It does not
> currently feature everything that BColumnListView features, like the
> built-in editing (IIRC), but I've written some simple code to add that
> (separately) in the new WonderBrush. This class could be the basis for a
> clean new BColumnListView class. One thing I didn't like so much about
> it, is that items can be accessed both via "global" index (i.e. what
> visual row), and by iterating over items via their parents. There seemed
> to be a mess regarding the question whether an index is relative to the
> parent or global, I'd like a clear distinction better. At the same time,
> it means more flexibility, if you can keep the overview. Ingo should say
> whether I should commit a version to the Haiku tree, so everyone can
> have a look.
As a base for designing the API I'd much prefer the Table/TreeTable classes
I created for DebugAnalyzer. ATM they do internally use BColumnListView,
but the API user is fully insulated from it and the intention is to get rid
of it eventually, implementing the functionality directly in the new
classes. If existing code could be borrowed, that would of course simplify
the job.
CU, Ingo
Other related posts:
