<div class="gmail_quote">On Sun, Oct 31, 2010 at 9:26 AM, Michael Jansen <span dir="ltr"><<a href="mailto:kde@michael-jansen.biz">kde@michael-jansen.biz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div class="im">On Sunday 31 October 2010 12:33:22 Mark Kretschmann wrote:<br>
> Hey all,<br>
><br>
> after reading the whole thread that started with Chani's mail ("why<br>
> kdelibs?"), I think the noise level has become a bit too much there.<br>
> Cornelius had proposed this rather daring idea:<br>
><br>
> <a href="http://lists.kde.org/?l=kde-core-devel&m=128842761708404&w=2" target="_blank">http://lists.kde.org/?l=kde-core-devel&m=128842761708404&w=2</a><br>
><br>
><br>
> It's a very controversial idea. However, I think it is so refreshing<br>
> that it deserves some more thought. Personally, I think the idea is<br>
> great, if we can overcome some of the obvious road blocks. I would<br>
> love to read some honest and direct thoughts from you guys.<br>
><br>
><br>
> What do you think about it?<br>
<br>
</div>
1. Small improvements to the Qt Libraries<br>
<br>
Those are the so called convenient classes. Classes the have been added to the<br>
KDE Libs because of some shortcomings of the Qt Classes or to add some<br>
convenience methods. I guess classes like KUrl and KIcon (at least parts) fall<br>
into that category.<br>
<br>
The classes in this category do not add additional functionality, requirements<br>
or anything else to the Qt Classes.<br></blockquote></div><br>I think this sounds like the place to start, for several reasons:<br><br>1. The changes to Qt should be relatively minor<br>2. These shouldn't change too rapidly, meaning Qt's release cycle won't be as big of a problem<br>

3. Backwards compatibility won't be affected (the relevant KDE libraries can be marked as deprecated and/or just be plain wrappers for the Qt version)<br>4. There is already probably some confusion about whether people should use the Qt or KDE version (KDE has a policy on this I think)<br>

5. Licensing shouldn't be as much of a problem<br>6. This is a prerequisite for moving larger parts over, since Qt libraries cannot make use of KDE convenience functions.<br><br>I think the second step would be to merge classes that subclass one existing Qt class to add additional features to that class.  These would be things that are mostly the same as the Qt version, but add some features to that version.<br>

<br>Third should be merging features from libraries that do the same thing as a Qt library, but implement it independently, One example that comes to mind is drag-and-drop between windows that is preventing some programs from using the Qt tab bar.<br>

<br>I think stuff that requires moving whole blocks of KDE over to Qt, like KIO, should be the last thing that is done.  This is partly because it is a lot more work, but also partly because, as I said in point 6, all the small KDE changes that the larger blocks depend on have to be in Qt anyway.<br>

<br>-Todd<br>