Proposing Quick Charts as a new framework

[Arjen Hiemstra]

On 06-09-2019 02:49, Aleix Pol wrote:
> On Thu, Sep 5, 2019 at 10:53 PM Arjen Hiemstra <ahiemstra at heimr.nl> 
> wrote:
>> 
>> On 02-09-2019 19:26, Luigi Toscano wrote:
>> > Arjen Hiemstra ha scritto:
>> >> Hi,
>> >>
>> >> I have been working on a library the past few months that provides a
>> >> QtQuick
>> >> module for rendering gpu-accelerated charts. It currently lives in a
>> >> playground
>> >> repository, here: https://invent.kde.org/kde/kf5quickcharts . I would
>> >> like for
>> >> this library to be included as a Tier 1 Framework.
>> >
>> > Hi,
>> > I've noticed that some time ago (I didn't enable the translations yet,
>> > but
>> > maybe it's not needed).
>> 
>> There are only user-visible strings in the example application. I
>> haven't marked them
>> to be translated since it is only an example.
>> 
>> > I have a question and a comment:
>> >
>> > - what is the difference between this one and the existing
>> > kqtquickcharts,
>> > part of the KDE Applications bundle, from the KDEEdu project? At least
>> > their
>> > description overlaps. Is there any transition path? Having two
>> > duplicate
>> > libraries with the exact same goal may not be the best scenario.
>> 
>> The main difference is in the rendering methods: kqtquickcharts uses
>> QPainter for
>> rendering, Quick Charts uses a technique called Signed Distance Fields
>> to render
>> certain charts with GPU acceleration and others use pure QtQuick
>> scenegraph. I
>> don't know if it would have been possible to retrofit that on to
>> kqtquickcharts,
>> but my guess is it would have been a major overhaul of that library
>> anyway.
>> 
>> An additional issue is that kqtquickcharts seems to be unmaintained,
>> with the last
>> major feature work having been done several years ago. So my personal
>> opinion is
>> that when Quick Charts is accepted as part of Frameworks, we deprecate
>> kqtquickcharts as well as some other bits like the plotter item from
>> kdeclarative.
> 
> Does it really have the same features? Otherwise it doesn't make sense
> to deprecate anything. It will just frustrate the users of the
> framework.

There is a significant amount of overlap. The kqtquickcharts library has 
a
few features that Quick Charts does not have, most but at the same time 
Quick
Charts has features kqtquickcharts does not have. Some of the things in
kqtquickcharts I had already planned to include, a few others would be 
nice
to include as well. I agree, however, that we should not just blindly
deprecate it.

> 
>> > - I don't think that "5" should be part of the name; in two years from
>> > now we
>> > may have a Frameworks 6, and having a kf5quickchart as part of it may
>> > be
>> > confusing.
>> 
>> That's actually a good point, though the kf5 is only in the repository
>> name, I
>> name it "Quick Charts" everywhere else. Which is probably a good 
>> reason
>> to have
>> the repo name changed in the first place. :) Originally, I put kf5 in
>> the repo
>> name because that's what is used once installed as part of Frameworks,
>> but I
>> agree that it can lead to confusing things.
> 
> It should be called kquickchart (which indeed is far too similar to
> kqtquickcharts). Much like you use KF5CoreAddons, but the repository
> is called kcoreaddons.

To be fair, KCoreAddons is called KCoreAddons in its documentation, so 
it
does not seem to be called "CoreAddons". At the same time, there are 
plenty
of Frameworks that do not start with a K, like Solid, Prison or BluezQt.
So I do not really see why it should be "kquickcharts".

- Arjen

> 
> Aleix