fix frameworks-kactions compile error

[Kevin Ottens]

On Sunday 15 April 2012 15:54:14 Stephen Kelly wrote:
> 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.

There's a difference with the example you give though, they have no clear 
competitor like KPlotWidget does.

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

Yes, that's why IMO KDChart/QwtPlot users probably would prefer not linking 
KPlotWidget because they use let's say KLed...

> > It's at least very much used in the edu world...
> 
> A reason not to put it in kde4support.

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

Right.
 
> 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. ;-)

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

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

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

Yep.
 
Cheers!
-- 
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/20120417/3685412d/attachment.sig>