[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KDE 4 Core Libraries major features
From:       Richard Dale <Richard_Dale () tipitina ! demon ! co ! uk>
Date:       2006-03-31 15:58:18
Message-ID: 200603311658.19340.Richard_Dale () tipitina ! demon ! co ! uk
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]