Questions about porting away from kdeui classes

[David Faure]

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