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, [email protected], http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 _______________________________________________ Kde-frameworks-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
