From kde-core-devel  Fri Mar 31 15:58:18 2006
From: Richard Dale <Richard_Dale () tipitina ! demon ! co ! uk>
Date: Fri, 31 Mar 2006 15:58:18 +0000
To: kde-core-devel
Subject: Re: KDE 4 Core Libraries major features
Message-Id: <200603311658.19340.Richard_Dale () tipitina ! demon ! co ! uk>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=114382272223455

On Friday 31 March 2006 16:31, Jaison Lee wrote:
> > > Another thing, which go in the general "api stability" category:
> > > What's going on with KListView ? should we start porting to QTreeWidget
> > > or similar ? or should we wait a K{List,Tree}{Widget,View} ?
> >
> > Start porting to QTree{View,Widget}, but if you notice any missing
> > feature that KListView used to provide and that you would need with
> > QTree{List,Widget}, then tell us or write it :)
> >
> > There was also a KTreeView or something class posted to kde-devel and
> > rudely turned down,  I'm not sure why.
>
> I don't think anyone was rude, but email is a funny thing. :)
>
> The proposal was met with several questions concerning the design of
> the implementation, and none of the more important ones were really
> answered well. The conversation veered into what should and shouldn't
> be done by a KTreeView, (namely a reimplementation of an Apple design
> widget) and then the conversation sort of dropped off.
Well, that was me talking about the Apple Cocoa NSBrowser widget. It might be 
true from a programmer's point of view that QTreeView looks completely 
different from NSBrowser. But from a user's viewpoint they are just different 
views of the same tree shaped model (eg a directory hierarchy), and the user 
might expect just some simple menu option to change from a tree view to a 
column browser view.

-- Richard