I moved this into the KDE Wiki so it will be easier to update. You can find it at <a href="http://wiki.kde.org/tiki-index.php?page=kdelibs4+TODO+Progess+Chart">http://wiki.kde.org/tiki-index.php?page=kdelibs4+TODO+Progess+Chart
</a> . <br><br>Greg<br>-<br><br><div><span class="gmail_quote">On 1/15/06, <b class="gmail_sendername">Gregory Hayes</b> <<a href="mailto:syncomm@gmail.com">syncomm@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<span class="q">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 tasks.
<br><br></span>BTW - PDF at <a href="http://www.icebreaker.net/kde4libs-todo.pdf" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.icebreaker.net/kde4libs-todo.pdf</a> if you cant view the OO attachment
<br><br>Greg<br>-<div><span class="e" id="q_108cdd5cfbe01438_2"><br><br><br><div><span class="gmail_quote">On 1/13/06, 
<b class="gmail_sendername">David Faure</b> <<a href="mailto:faure@kde.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">faure@kde.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Laurent Montel just asked me today what he could do to help with kde4.<br><br>In my opinion, we need to focus on kdelibs first. We can't write/rewrite<br>proper Qt4-based apps without support from kdelibs, since parts of kdelibs
<br>are currently still using Q3 classes and concepts.<br><br>- To start with, check kdelibs/TODO. There's a huge number of things listed there.<br><br>- Of course there's the on-going effort to port away from Q3 classes. For collection
<br>classes it's easy (but far from done yet, see e.g. "grep q3ptr kdeui/*.h"),<br>but see below for less obvious things.<br><br>- Keep in mind the big picture: <a href="http://developer.kde.org/%7Edanimo/kde4foundation.png" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

http://developer.kde.org/~danimo/kde4foundation.png</a><br>In particular this means (if we still agree on this) we'll have in kdelibs:<br>components/core, components/gui, framework/core, framework/gui<br>instead of just kdecore, kdeui. For this reason I have stopped moving things to
<br>kdecore/kdeui, we first need to start with this split.<br><br>- KIconView/KListView equivalents based on Qt4 interview. As discussed on kde-core-devel,<br>this probably means a custom QItemDelegate instead, to handle single-click/double-click,
<br>execute-mode/select-mode (cf KIconView), number of lines used for wrapping, "held" signal.<br>In short, rewriting kiconview features to be based on interview.<br>For KListView we need to check if QTreeView supports both modes of drag-n-drop (dropping
<br>onto items, and dropping between items like in the bookmark editor).<br><br>- Port KMainWindow/KToolBar to QMainWindow/QToolBar. Evaluate if we need to<br>keep the old ones in kde3support depending on the differences.
<br><br>- Port the rest of kdeui classes away from Q3 base classes:<br> KActiveLabel, KColorDialog, KCompletionBox, KSyntaxHighlighter<br>(what's KSelector?). etc.<br><br>... for all those things, don't just port blindly. Use or write test programs in kdeui/tests,
<br>to experiment with the Qt4 classes and then with your additions to them.<br><br>- Many KIO classes are "core only" and should move to kdecore<br>KArchive and derivatives, KACL -> core (probably components/core)
<br>KURIFilter, KEMailSettings, K*Share -> core  (probably framework/core)<br>So before moving things to kdecore, I want to make sure everyone's ok (at least aware :) )<br>of the planned components / framework separation and then we can start moving
<br>stuff to the right place. To do this smoothly we could start with moving everything<br>to framework for now, and considering moving individual things to components<br>as we go along. Reminder: the idea of components is simply that those classes
<br>should be useable without dependencies on other kde classes. Think "would I<br>be able to use this class in a Qt-only project, by just copying it over". This excludes<br>anything KConfig/KStandardDirs-based, or anything KIO-based of course.
<br><br>- For KIO jobs it's more tricky, we'll have to think of a way to split core from gui,<br>not sure how yet. Proposals welcome.<br><br>Well, and many other things, but I'll stop here for now. This isn't an exhaustive
<br>list, it's just a few ideas for those who have hacking time but don't know what<br>to do with it :)<br><br>I guess I should extend kdelibs/TODO with some of the items above,<br>but it's so big already :)<br><br>--<br>

David Faure, <a href="mailto:faure@kde.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">faure@kde.org</a>, sponsored by Trolltech to work on KDE,<br>Konqueror (<a href="http://www.konqueror.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://www.konqueror.org</a>), and KOffice (<a href="http://www.koffice.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://www.koffice.org</a>).<br><br></blockquote></div><br>

</span></div><br clear="all"></blockquote></div><br>