Questions about porting away from kdeui classes

[Mark]

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. I also think
KCompletion can be made more memory efficient by borrowing some
concepts of http://en.wikipedia.org/wiki/Radix_tree but that's a
completely different thing (something i looked into last night when i
was interested in how KCompletion actually works) :)
>
> The only difference is that KCompletion doesn't know any widgets, so it has
> proper core/gui separation (the gui listens to the core object), while
> QCompleter pushes data to a QWidget directly.
>
>> I would say that
>> KCompletion needs to go to Qt, but not in QCompleter, but as
>> QCompleter' base.
>>
>> QCompleter : public QCompleterBase
>
> I don't think this makes sense with the current code, given the "signal" vs
> "direct call" difference. KCompletion emits signals, so it's probably better
> used by composition (member object) than inheritance. Also, you don't want to
> suddenly provide both APIs to users of QCompleter, IMHO.
>
> The name "QCompleterBase" being so vague shows that this isn't the right class
> design. If it was right, the name would be more descriptive :)

:) I was just making things up as i wrote it down. I don't know a better name.
>
>> How does that sound to you?
>> No, i'm not volunteering (yet) to take this one since i have enough on
>> my todo list as it is :)
>
> As long as nobody is really volunteering for this, I think KCompletion should
> just stay in kdelibs. We have many other things that are much easier to
> upstream into Qt, let's postpone this one IMHO.

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
>
> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
>