fix frameworks-kactions compile error

[Stephen Kelly]

Kevin Ottens wrote:
>> kplotting also doesn't depend on either of the above plotting engines,
>> let alone both of them, so I guess I didn't understand what you wrote
>> here or why having kplotwidget grouped with other widgets would mean
>> dragging them in.
> 
> I meant that someone who would want to do serious plotting and use our
> widgets would link to kwidgetsaddons and to KDChart or QwtPlot, or
> something else. If the content of kplotting is in kwidgetsaddons, it'd end
> up linking in both kplotting and the plotting engine he really wanted,
> that's the thing I was pointing out.

Right, but that will always be the case anyway. If KLed and KCapacityBar are 
both in kwidgetsaddons, but you only want to use KLed, you're going to be 
using a library containing a widget you don't use anyway. The same is true 
of Qt. If you don't use the modelview system or the QTreeWidget etc, they're 
still there in QtGui anyway. Whatever argument for kplotwidget to not be 
grouped together with other 'KDE free-agent-widgets' applies equally to many 
other comparable situations.

That said, if you think it really matters, I won't merge them.

> Now maybe kplotting is tiny enough that we don't care... But then it could
> even raise the question of "should it go in kde4support? and we push for
> an alternative?" 

The users of KPlotWidget probably don't need what KDChart or QwtPlot 
provide. Otherwise they'd be using one of them already.

> It's at least very much used in the edu world... 

A reason not to put it in kde4support.

> And I'm
> not sure if we're well placed to make that call, hence the idea to have it
> separated.

Even if we're not well placed to affirmatively put it in kde4support (Though 
I don't see the need), I think we are well placed to make the call to keep 
it in a separate framework or not.

> 
> Did I make more sense now? :-)

Yes. I think it's small enough that we shouldn't care :). 

I think there's more interesting things to put energy into, so I don't think 
we need to discuss it anymore. 

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

> 
>> >> This is only a partial selection of the widgets available already with
>> >> some definite candidates to populate a kwidgetsaddons library like I
>> >> described, so I'm sure creating such a framework would be worth it.
>> > 
>> > 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. 

Whether and to what extent we should use or encourage the use of 
Q{Core,Gui,}Application instead of KApplication is not related to whether 
KCapacityBar should be in kde_ui_integration or kwidgetsaddons. There is no 
QCapacityBar.

Anyway, I added a link to this thread here:

http://community.kde.org/Frameworks/Epics/Splitting_kdelibs#April_Iteration

Thanks,

Steve.