On Sun, Jul 1, 2012 at 3:36 PM, David Faure <[email protected]> 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, [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
