Questions about porting away from kdeui classes

[David Faure]

On Sunday 01 July 2012 16:24:51 Mark wrote:
> On Sun, Jul 1, 2012 at 3:36 PM, David Faure <faure at kde.org> wrote:
> > On Sunday 01 July 2012 14:07:15 Mark wrote:
> >> On a related note for KCompletion vs QCompleter.
> >> I don't think the two should merge.
> > 
> > I agree :)
> > 
> >> QCompleter is very UI orientated
> >> and really meant to hook on to a input field.
> >> KCompletion is much more basic, it simply completes the data that's
> >> fed into with the string that's being searched for.
> > 
> > Right but it's mostly useful in a widget, in the end...
> 
> Currently, yes. However, QML doesn't have any forms of completion at
> this moment and that would really be useful in some cases. This is
> where KCompletion has a lot more value then QCompleter. 

Right. That would be a good argument for getting a new completion framework 
into Qt, which would also address KDE's needs.

> Yep. First thing would be cleaning up the KCompletion API anyway at
> which point the cleaned up API moves to KF5 or Qt 5.x

We cannot move old code from KDE to Qt.
Mainly because of the licensing issues (past contributors didn't sign the Qt 
CLA), but also because APIs in Qt are usually different (more often value 
based, etc.), and the implementation itself, well, could benefit from a 
rewrite.

But yes, just like I did with QStandardPaths, QMimeType and others, the 
solution is to write clean Qt code from scratch and put that into Qt.

The good thing compared to before OpenGov is that, even if we don't have time 
to do it now, we can at least monitor the Qt development list in order to 
react and give input if anyone starts working on a new completion framework 
for QtGui...

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5