kdelibs (partial) todo list

[David Faure]

Laurent Montel just asked me today what he could do to help with kde4.

In my opinion, we need to focus on kdelibs first. We can't write/rewrite 
proper Qt4-based apps without support from kdelibs, since parts of kdelibs
are currently still using Q3 classes and concepts.

- To start with, check kdelibs/TODO. There's a huge number of things listed there.

- Of course there's the on-going effort to port away from Q3 classes. For collection
classes it's easy (but far from done yet, see e.g. "grep q3ptr kdeui/*.h"), 
but see below for less obvious things.

- Keep in mind the big picture: http://developer.kde.org/~danimo/kde4foundation.png
In particular this means (if we still agree on this) we'll have in kdelibs:
components/core, components/gui, framework/core, framework/gui
instead of just kdecore, kdeui. For this reason I have stopped moving things to
kdecore/kdeui, we first need to start with this split.

- KIconView/KListView equivalents based on Qt4 interview. As discussed on kde-core-devel,
this probably means a custom QItemDelegate instead, to handle single-click/double-click,
execute-mode/select-mode (cf KIconView), number of lines used for wrapping, "held" signal.
In short, rewriting kiconview features to be based on interview.
For KListView we need to check if QTreeView supports both modes of drag-n-drop (dropping
onto items, and dropping between items like in the bookmark editor).

- Port KMainWindow/KToolBar to QMainWindow/QToolBar. Evaluate if we need to
keep the old ones in kde3support depending on the differences.

- Port the rest of kdeui classes away from Q3 base classes:
 KActiveLabel, KColorDialog, KCompletionBox, KSyntaxHighlighter
(what's KSelector?). etc.

... for all those things, don't just port blindly. Use or write test programs in kdeui/tests,
to experiment with the Qt4 classes and then with your additions to them.

- Many KIO classes are "core only" and should move to kdecore
KArchive and derivatives, KACL -> core (probably components/core)
KURIFilter, KEMailSettings, K*Share -> core  (probably framework/core)
So before moving things to kdecore, I want to make sure everyone's ok (at least aware :) )
of the planned components / framework separation and then we can start moving 
stuff to the right place. To do this smoothly we could start with moving everything
to framework for now, and considering moving individual things to components
as we go along. Reminder: the idea of components is simply that those classes
should be useable without dependencies on other kde classes. Think "would I
be able to use this class in a Qt-only project, by just copying it over". This excludes
anything KConfig/KStandardDirs-based, or anything KIO-based of course.

- For KIO jobs it's more tricky, we'll have to think of a way to split core from gui, 
not sure how yet. Proposals welcome.

Well, and many other things, but I'll stop here for now. This isn't an exhaustive
list, it's just a few ideas for those who have hacking time but don't know what
to do with it :)

I guess I should extend kdelibs/TODO with some of the items above,
but it's so big already :)

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).