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

List:       kde-core-devel
Subject:    Re: KTreeList
From:       Cristian Tibirna <ctibirna () total ! net>
Date:       1999-07-11 16:57:52
[Download RAW message or body]

On Sun, 11 Jul 1999, Stefan Taferner wrote:

> Am Sat, 10 Jul 1999 schrieb Dirk A. Mueller:
> > Hi,
> > 
> > any objections against removing kdelibs/kdeui/KTreeList ?
> 
> Not if you move it over into some kde-compat lib.
>  
> > QListView is more powerful and looks nicer, anyway. Although the API's
> > are not really the same, it's quite easy to port existing apps to the
> > new api. I did it for the OpenWithDlg this evening and it took only an
> > hour including figuring out where the differences are.
> > 
> > Anyway, only very few apps use it at the moment (kppp, krn, some
> > koffice).
> > 
> > KTreeList is really quite big and could be replaced so easily...
> > I even volunteer fixing the other apps. Comments please.
> 
> I don't think that you know all "other" apps. There might be apps that
> are not even in CVS or FTP.

Since all kde-1.X compat apps "out there" have to be touched in order to
make them kde-2.X compatible, I think it's much better to encourage
authors to have this one aspect (among many other) taken care of too. If
QListView an KTreeList have equivalent functionality and KTreeList has no
compelling advantage, I'd much more favour take it out.

What I think it's a very important thing here is *detailed*, I stress
*very detailed* information on how to convert KDE-1.X apps to KDE-2.X.
KDE2PORTING is a start, but I can give the counter-example of how DnD
matters are described in that document.

heh :-) if we weren't a team volutary coders, our (presumable) boss would
have had to declare a moratory period where only bugs be fixed or bug
reports dealt with (look at how many bugs are in the bugs.kde.org) and
development documentation be written. (I am surely the least recommended
person to speak about this, as I didn't do much in this sense later too).

> I strongly vote for having a lib in kdesupport package that contains all
> the old stuff. Or even put it into kdenonbeta. But put it somewhere, so
> that programmers who need these classes can fetch them after
> removal.

I think puting it in kdenonbeta would be better.

Cristian

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