kdelibs (partial) todo list
syncomm at gmail.com
Sun Jan 15 11:31:47 GMT 2006
I went ahead and collected the items in the kdelibs TODO (along with these
suggestions) and moved them into a simple spreadsheet. I added some columns
for data we are not tracking in the TODO, like "Estimated Hours of Work",
difficulty, % complete, etc. Let me know if this is helpful. I would be
interested in keeping it up to date and filling in more information on these
BTW - PDF at http://www.icebreaker.net/kde4libs-todo.pdf if you cant view
the OO attachment
On 1/13/06, David Faure <faure at kde.org> wrote:
> 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
> classes it's easy (but far from done yet, see e.g. "grep q3ptr
> but see below for less obvious things.
> - Keep in mind the big picture:
> In particular this means (if we still agree on this) we'll have in
> 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
> this probably means a custom QItemDelegate instead, to handle
> 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
> 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
> stuff to the right place. To do this smoothly we could start with moving
> to framework for now, and considering moving individual things to
> as we go along. Reminder: the idea of components is simply that those
> should be useable without dependencies on other kde classes. Think "would
> 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
> list, it's just a few ideas for those who have hacking time but don't know
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 18667 bytes
Desc: not available
More information about the kde-core-devel