Re: Proposing Quick Charts as a new framework
On 18-09-2019 12:06, Arjen Hiemstra wrote: On 06-09-2019 11:02, Semke, Alexander wrote: Am 06.09.2019 um 02:49 schrieb Aleix Pol : 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. Qt has https://doc.qt.io/qt-5/qtcharts-index.html. Does kqtquickcharts or this new framework provide more features? Personally, I consider the QtQuick side of QtCharts to be barely usable, since it just wraps the QtWidgets bits and embeds them in your QtQuick scene. This leads to all sorts of weird issues. (Looks like part of my message got lost, here's the rest:) Again, the most major difference is that Quick Charts is completely built to use GPU accelerated rendering. Currently it does not have the same features as QtCharts but there is no reason the feature set cannot be expanded. - Arjen — Alexander
Re: Proposing Quick Charts as a new framework
On 06-09-2019 11:02, Semke, Alexander wrote: Am 06.09.2019 um 02:49 schrieb Aleix Pol : 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. Qt has https://doc.qt.io/qt-5/qtcharts-index.html. Does kqtquickcharts or this new framework provide more features? Personally, I consider the QtQuick side of QtCharts to be barely usable, since it just wraps the QtWidgets bits and embeds them in your QtQuick scene. This leads to all sorts of weird issues. Again, the most major difference is that Quick Charts is completely built on top o — Alexander
Re: Proposing Quick Charts as a new framework
On 09-09-2019 10:24, Dominik Haumann wrote: Hi, On Sat, Sep 7, 2019 at 3:59 PM Arjen Hiemstra wrote: On 06-09-2019 02:49, Aleix Pol wrote: On Thu, Sep 5, 2019 at 10:53 PM Arjen Hiemstra wrote: On 02-09-2019 19:26, Luigi Toscano wrote: Arjen Hiemstra ha scritto: [...] 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". Just my 2 cents: The reason is consistency. Don't underestimate consistency. We have done naming mistakes from time to time, but that should not imply we should do it again. +1 for KQuickCharts, names do matter. At the same time, I could argue that we are trying to move away from k- names in applications and might want to do the same for other parts of KDE. But let's not argue semantics, if people insist on kquickcharts I will change it to kquickcharts. Best regards Dominik
Re: Proposing Quick Charts as a new framework
Hi, On Sat, Sep 7, 2019 at 3:59 PM Arjen Hiemstra wrote: > On 06-09-2019 02:49, Aleix Pol wrote: > > On Thu, Sep 5, 2019 at 10:53 PM Arjen Hiemstra > > wrote: > >> > >> On 02-09-2019 19:26, Luigi Toscano wrote: > >> > Arjen Hiemstra ha scritto: > [...] > >> 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". > Just my 2 cents: The reason is consistency. Don't underestimate consistency. We have done naming mistakes from time to time, but that should not imply we should do it again. +1 for KQuickCharts, names do matter. Best regards Dominik
Re: Proposing Quick Charts as a new framework
On 06-09-2019 02:49, Aleix Pol wrote: On Thu, Sep 5, 2019 at 10:53 PM Arjen Hiemstra 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
Re: Proposing Quick Charts as a new framework
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. - 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. Cheers, Arjen Ciao
Re: Proposing Quick Charts as a new framework
> Am 06.09.2019 um 02:49 schrieb Aleix Pol : > > 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. Qt has https://doc.qt.io/qt-5/qtcharts-index.html. Does kqtquickcharts or this new framework provide more features? — Alexander
Re: Proposing Quick Charts as a new framework
On Thu, Sep 5, 2019 at 10:53 PM Arjen Hiemstra 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. > > - 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. Aleix
Re: Proposing Quick Charts as a new framework
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). 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. - 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. Ciao -- Luigi
