On 06-09-2019 02:49, Aleix Pol wrote:
On Thu, Sep 5, 2019 at 10:53 PM Arjen Hiemstra <ahiems...@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

Reply via email to