Questions about porting away from kdeui classes

[Mark]

On Sun, Jul 1, 2012 at 8:39 AM, David Faure <faure at kde.org> 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, faure at kde.org, http://www.davidfaure.fr
> Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
>
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> 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