fix frameworks-kactions compile error

[Stephen Kelly]

Kevin Ottens wrote:

> On Sunday 15 April 2012 15:54:14 Stephen Kelly wrote:
>> It might be useful to have an objective way to know whether a widget
>> should be on a framework on its own or grouped with something else
>> though. Does size matter?
>> 
>> Personally I think it should be something like expected utility to Qt
>> developers.
> 
> Not really an objective criterion though. ;-)

It's not fully subjective either. Creating a QTextCodec plugin was done so 
seldom in Qt4 that the possibility was removed in Qt5. I've never known 
anyone to implement their own codec. The text part (irrelevant to most Qt 
developers) more than doubles the size of the library:

$ du -h
72K     ./jobs
76K     ./kernel
256K    ./text/probers/tables                                                                          
616K    ./text/probers                                                                                 
884K    ./text                                                                                         
156K    ./caching                                                                                      
28K     ./randomness                                                                                   
180K    ./io                                                                                           
1.4M    .

>> For example, I think the text/ directory in kcoreaddons should
>> be moved into a separate framework (almost no Qt developers need
>> additional codecs beyond what's provided with Qt), and itemmodels should
>> be merged into kcoreaddons.
> 
> Although I tend to agree, I'm not sure it helps in the general case...
> Same could be said for caching/ and io/ subfolders than text/ probably.

Well, I've said before that I'd prefer to put lots of that stuff into a 
KMultiProcess framework. :) KLockFile, KSharedDataCache (I'm not sure if 
KDirWatch needs to still exist, given that there is a Qt equivalent). Given 
that splitting those would leave many tiny frameworks, I agree with grouping 
them. The other classes in the library are things that other Qt developers 
would find the need for if they knew it exists - KBackup, KAutoSaveFile.

> 
>> >> > Could you bring those notes to the newly created page, the comment
>> >> > column is here for that:
>> >> > http://community.kde.org/Frameworks/Epics/Reduce_class_duplication
>> >> 
>> >> Are you sure? These are not 'de-duplication' tasks.
>> > 
>> > Yeah, wasn't really inspired for the page name... and since it's in
>> > part about deciding between keep/push in Qt I settled on the
>> > "duplication" term. Feel free to rename it if you got a better one.
>> 
>> What I mean is, the items on that wiki page are de-duplication tasks, but
>> the items I wrote about the widgets in my previous email are not de-
>> duplication tasks.
> 
> Yes, that's why I don't like the name of the page I created, it's not only
> about de-duplication, it's more generally about deciding what we will do
> of the widgets. 

Many of them are not widgets.

> For some of them yes the conclusion will be to
> de-duplicate and merging relevan parts to Qt, for some other the
> conclusion might be "cleanup and move in kwidgetsaddons".

I don't get the connection between the two lists of tasks, but I'll happily 
leave wiki and categorization on your plate.

> I really see this page helping with the decision process for all those
> classes, not just "acting" on the decision. If it can be acted upon right
> away when we get a decision the better, otherwise it'll probably generate
> more tasks in other pages (kdelibs cleanups or Qt 5.x pages come to mind).

Thanks,

Steve.