Questions about porting away from kdeui classes

[David Faure]

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...

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 :)

> 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.

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