fix frameworks-kactions compile error

[Kevin Ottens]

On Wednesday 18 April 2012 10:21:36 Stephen Kelly wrote:
> 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    .

Good point.

> >> 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. :)

Well, if I remember correctly last time we discussed this the conclusion was 
"the list is still too short". Now if it expanded, it could be revisited of 
course.

> KLockFile, KSharedDataCache (I'm not sure if
> KDirWatch needs to still exist, given that there is a Qt equivalent).

Yes, I've been wondering about KDirWatch lately... We used to keep it because 
of some QFileSystemWatcher limitations. Maybe it's not relevant anymore, IIRC 
David had the details.

> 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.

Right.

> >> >> > 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.

Damned, "classes", I meant "classes". *sigh*

> > 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.

Hm, maybe that's me missing something then. The current list we have on the 
"Reduce class duplication" page right now is about deciding for each of the 
classes listed there if:
 * it goes to kde4support being obsoleted by a Qt class;
 * or needs porting some of its features to Qt5 before moving to kde4support;
 * or provides novelty so needs to go in a framework TBD;
 * or it's purely KDE apps integration so it goes in the Tier 4 integration 
framework.

Is it different from the work needed for the widgets? Or you were done with 
the decision process perhaps? (kind of assumed it was still on going).
 
Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120418/960a6804/attachment.sig>