On Sun, Jul 1, 2012 at 8:39 AM, David Faure <[email protected]> wrote: > On Wednesday 27 June 2012 12:08:51 Eike Hein wrote: >> Hi, >> >> lately I'm seeing an increasing number of commits that >> port things away from kdeui classes, e.g. this one: >> >> http://commits.kde.org/kdelibs/c87a6aa >> >> I'd like to learn more about what is being done there, >> as well as the reasons and goals. >> >> For example, the commit in question feels deceptively >> simple to me. KInputDialog spawns KDialogs containing >> their own K* widgets, e.g. KLineEdit. KLineEdit has >> a lot of features over its Qt counterpart, along with >> integration with KDE's standard action shortcut system, >> our spell-checking system, our TTS system ... from what >> I can see, all of this is lost by porting to QInput- >> Dialog, and I haven't seen any discussion or merge >> requests compensating for this on the Qt side. > > The features that KLineEdit has over QLineEdit are not used in > KInputDialog::getText. > As far as I could see, the KLineEdit features are > - the clear button, which I plan on adding to Qt 5.1 (*) > - support for text squeezing, also for Qt 5.1, unused in KInputDialog anyway > - support for URL drops, also for Qt 5.1 > - support for the KCompletion framework -- which will be a good reason to keep > KLineEdit around (and possibly rename it to KCompletionLineEdit if this is the > only feature left in the end), but this isn't used in KInputDialog::getText. > The code related to kactions is only used for choosing the type of completion. > > I don't see any code in KLineEdit that integrates it to KTTS or sonnet, I > think you made up features in your email :-) > > > (*) http://community.kde.org/Frameworks/Epics/Qt_5.1_Merging > > The feature freeze in Qt is forcing us to wait a bit until we can get the > necessary new features in, but that's OK, because we have much to do meanwhile > anyway, and it's clear that frameworks won't be ready before Qt-5.1 exists > anyway. > > -- > 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
On a related note for KCompletion vs QCompleter. I don't think the two should merge. 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. I would say that KCompletion needs to go to Qt, but not in QCompleter, but as QCompleter' base. QCompleter : public QCompleterBase Where QCompleterBase would be what KCompletion is right now. The API for KCompletion also looks a bit off compared to Qt based API's so there needs to be a bit of cleaning up in KCompletion as well. 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 :) Cheers, Mark _______________________________________________ Kde-frameworks-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
