fix frameworks-kactions compile error

Kevin Ottens ervin at kde.org
Sat Apr 14 21:06:59 UTC 2012


On Saturday 14 April 2012 19:19:51 Stephen Kelly wrote:
> Kevin Ottens wrote:
> > On Wednesday 11 April 2012 23:34:18 Stephen Kelly wrote:
> >> So here's my proposal:
> >> 
> >> * kplotting should be renamed and repurposed as kwidgetsaddons (tier1), a
> >> framework which depends only on QtWidgets. The widgets in there should be
> >> self-contained and not rely on any 'KDE stuff' (This is one of the
> >> central goals of the frameworks effort and the only reason to move stuff
> >> around at this point). I had to choose the kwidgetsaddons name because
> >> kwidgets exists,
> > 
> > Not sure if having kplotting grouped with the rest is a good idea,
> > definitely looked like something which could stand on its own as a cheap
> > plotting solution.
> 
> Too cheap to be on it's own IMO. Someone who really wants to do plotting
> wouldn't be using it, they'd use a KDChart or Qwt.
> 
> > Also AFAIK it's doomed to have at least two competitors, so someone who
> > wants to do plotting and use some of our widgets probably don't want to
> > drag two plotting engines.
> 
> 'At least two competitors' = KDChart and QwtPlot?

Yes.
 
> Those are far more complete than the kplotting widget. They're really not
> comparable at all in terms of complexity or use-cases.

Yes.

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

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?" It's at least very much used in the edu world... And I'm not 
sure if we're well placed to make that call, hence the idea to have it 
separated.

Did I make more sense now? :-)

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

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/20120414/76394611/attachment.sig>


More information about the Kde-frameworks-devel mailing list