[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: kdelibs (partial) todo list
From: Gregory Hayes <syncomm () gmail ! com>
Date: 2006-01-15 11:31:47
Message-ID: 9f573ec50601150331p19c86642u140f817087901ae2 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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 thes=
e
tasks.
BTW - PDF at http://www.icebreaker.net/kde4libs-todo.pdf if you cant view
the OO attachment
Greg
-
On 1/13/06, David Faure <faure@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 kdelib=
s
> 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 kno=
w
> 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@kde.org, sponsored by Trolltech to work on KDE,
> Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org
> ).
>
>
[Attachment #5 (text/html)]
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>BTW - PDF at <a \
href="http://www.icebreaker.net/kde4libs-todo.pdf">http://www.icebreaker.net/kde4libs-todo.pdf</a> \
if you cant view the OO attachment<br><br>Greg<br>-<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">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/~danimo/kde4foundation.png"> \
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">faure@kde.org</a>, \
sponsored by Trolltech to work on KDE,<br>Konqueror (<a \
href="http://www.konqueror.org">http://www.konqueror.org</a>), and KOffice (<a \
href="http://www.koffice.org"> \
http://www.koffice.org</a>).<br><br></blockquote></div><br>
["kde4libs-todo.ods" (application/vnd.oasis.opendocument.spreadsheet)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic