Re: Quick Charts in KDE Review
Am Samstag, 9. November 2019, 14:16:08 CET schrieb David Edmundson: > > If one restricts oneself to use only libraries part of KDE Frameworks, but > > not from the "Extragear" domain, one should reconsider it, this does not > > make much sense as long one also uses non-KDE-party libraries (which also > > do not follow KF rules). > > Plasma effectively has such a rule. > > Treating this as a more meta discussion about libs, sure, with KDE > rules in extragear you can change ABI/API but the consequences still > mean in reality you can't. > Release an incompatible lib, things explode until recompiled. I am confused this is assuming one releases an incompatible library not using respective versioning schemes and not allowing parallel install? But people do that properly, no? > If we use a lib in plasma and in an application and then change the > lib API we always have a window where either applications latest > release or plasma latest release won't compile against the released > lib. Even if you bump the .so version Why the "even"? One should. That's what the purpose of the so version is. > the headers aren't > co-installable. Some projects do proper version namespaces also for include path on changed ABI. If projects do not, they should start to do IMHO. Even without, normally developers only work against one version of the library, so just having one variant of headers installed works good enough. > Due to this release problem Plasma has previously made any use of > extragear (or unstable 3rd party) #ifdef'd and always not in core > functionality. Given Plasma requires recent versions of KF on .0 releases, the same can be done also for newer versions of non-KF libraries, where one then switches to the new API series. No need for #ifdef. > >But I recommend to do as others and not bind to > > current first ABI for some time to come > > Note this is all somewhat moot for this specific case. There is only a > QML import. It can change ABI all it wants. Changing API is also > doable as long as QML import bumps and the old version still works. That is no different to normal compiled library symbols, no? One also cannot break "ABI" (not sure what the respective name would be in dynamic languages), i.e. change names of symbols or their types at QML layer. Think QQC 1 and QQC 2. Of course this comes at cost. But personally I am willing to pay that price over having to stick with API which proved to be not good enough and thus makes my own code worse. Thus my 2 cent recommendation to stay flexible for now :) But everyone has different priorities, just wanted to make you consider this. Cheers Friedrich
Re: Quick Charts in KDE Review
> If one restricts oneself to use only libraries part of KDE Frameworks, but not > from the "Extragear" domain, one should reconsider it, this does not make much > sense as long one also uses non-KDE-party libraries (which also do not follow > KF rules). Plasma effectively has such a rule. Treating this as a more meta discussion about libs, sure, with KDE rules in extragear you can change ABI/API but the consequences still mean in reality you can't. Release an incompatible lib, things explode until recompiled. If we use a lib in plasma and in an application and then change the lib API we always have a window where either applications latest release or plasma latest release won't compile against the released lib. Even if you bump the .so version the headers aren't co-installable. Being in this situation where we break ourselves means every packager would murder you on sight. Due to this release problem Plasma has previously made any use of extragear (or unstable 3rd party) #ifdef'd and always not in core functionality. >But I recommend to do as others and not bind to current first ABI for some time to come Note this is all somewhat moot for this specific case. There is only a QML import. It can change ABI all it wants. Changing API is also doable as long as QML import bumps and the old version still works.
Re: Quick Charts in KDE Review
Am Donnerstag, 7. November 2019, 16:21:40 CET schrieb Nate Graham: > On 11/7/19 7:34 AM, Friedrich W. H. Kossebau wrote: > > Am Montag, 21. Oktober 2019, 15:22:23 CET schrieb Arjen Hiemstra: > >> Quick Charts is a QML module that implements a set of high-performance, > >> GPU accelerated > >> charts. Currently the main user of it is a new KSysGuard UI I have been > >> working on, but > >> once it is part of Frameworks I also hope to convert several bits of > >> Plasma to using it. > > > > If there is only one user currently, might it perhaps be a better idea to > > do some independent releases for a while to get more feedback on the API, > > before settling to the API freeze by being part of KDE Frameworks? It > > will be at least a year until KF6 is there to properly fix up any > > potential API inconveniences which users might find. > > I would at least recommend to first get some API shaping by real-world > > exposure. > > Seems like a chicken-egg problem: more exposure would be provided by > getting it through the review process, no? I can see us porting the > graphs in KInfoCenter to use this, for example. But since that's > shipping code, we might not want to do that until it's formally a framework. If one restricts oneself to use only libraries part of KDE Frameworks, but not from the "Extragear" domain, one should reconsider it, this does not make much sense as long one also uses non-KDE-party libraries (which also do not follow KF rules). Review process is about passing something from playground into the set of no- longer-playground repos. Which for libs can be KDE Frameworks domain, but also the "Extragear" domain. Both are equally post-review. And "Extragear" gives the flexibility to do another product version with different ABI, once there has been more feedback from more users. An approach e.g. taken by KUserFeedback. But also compare the concept of Qt labs modules. Having an API mainly done for one user only right now runs a good chance to miss the API needs of other potential candidates. Everyone needs a different 20 % of the API concepts, they say when throwing with numbers ;) Np chicken-egg problem here. Release-often-and-early should be simply applied to KChickCharts as well. But I recommend to do as others and not bind to current first ABI for some time to come, like begin of KF6, instead plan for some optional ABI-breaking releases in the near future. So be under the rules of Extragear, not yet Frameworks. But people learn best from own mistakes, so feel free to ignore some old person's comment-from-experience. ;) If the API proves to be not perfect and one knows how it would be better, ~12 months (to KF6) can be very long :P Cheers Friedrich
Re: Quick Charts in KDE Review
On 07-11-2019 15:34, Friedrich W. H. Kossebau wrote: Am Montag, 21. Oktober 2019, 15:22:23 CET schrieb Arjen Hiemstra: Hi, Quick Charts has been moved to KDE review. The intent is to make it a Tier 1 framework. Any chance the official name can be "KQuickCharts"? "Quick Charts" is a generic name which only asks for being misunderstood, is hard to google etc.. Fair point. Since the repo is already kquickcharts, I will update the documentation to match. Quick Charts is a QML module that implements a set of high-performance, GPU accelerated charts. Currently the main user of it is a new KSysGuard UI I have been working on, but once it is part of Frameworks I also hope to convert several bits of Plasma to using it. If there is only one user currently, might it perhaps be a better idea to do some independent releases for a while to get more feedback on the API, before settling to the API freeze by being part of KDE Frameworks? It will be at least a year until KF6 is there to properly fix up any potential API inconveniences which users might find. I would at least recommend to first get some API shaping by real-world exposure. So there is one known user currently, KSysGuard. Additionally, there are several places in Plasma that I want to look at to use them. There is also the KInfoCenter energy information page where we want to look at using this. Additionally, there has been some interest from others. I do not know what Plasma's policy is regarding dependencies, but having it in Frameworks would make things quite a bit simpler to port existing things. The module has been in development for about 5 months at this point. We have been using it for the mentioned new KSysGuard UI as well as some other bits we want to upstream. At this point, I am fairly sure that any major API changes would amount to a "KF6" version anyway. I would rather commit to the stable API so that people will know there is no large chance of things suddenly changing from underneath them. - Arjen Sorry otherwise for not reviewing myself, not into QML the recent months. Cheers Friedrich
Re: Quick Charts in KDE Review
On 11/7/19 7:34 AM, Friedrich W. H. Kossebau wrote: Am Montag, 21. Oktober 2019, 15:22:23 CET schrieb Arjen Hiemstra: Hi, Quick Charts has been moved to KDE review. The intent is to make it a Tier 1 framework. Any chance the official name can be "KQuickCharts"? "Quick Charts" is a generic name which only asks for being misunderstood, is hard to google etc.. Quick Charts is a QML module that implements a set of high-performance, GPU accelerated charts. Currently the main user of it is a new KSysGuard UI I have been working on, but once it is part of Frameworks I also hope to convert several bits of Plasma to using it. If there is only one user currently, might it perhaps be a better idea to do some independent releases for a while to get more feedback on the API, before settling to the API freeze by being part of KDE Frameworks? It will be at least a year until KF6 is there to properly fix up any potential API inconveniences which users might find. I would at least recommend to first get some API shaping by real-world exposure. Seems like a chicken-egg problem: more exposure would be provided by getting it through the review process, no? I can see us porting the graphs in KInfoCenter to use this, for example. But since that's shipping code, we might not want to do that until it's formally a framework. +1 for making it a framework sooner rather than later. Nate
Re: Quick Charts in KDE Review
On 07-11-2019 15:24, Alexander Potashev wrote: чт, 7 нояб. 2019 г. в 13:53, Arjen Hiemstra : On 21-10-2019 15:22, Arjen Hiemstra wrote: > Hi, > > Quick Charts has been moved to KDE review. The intent is to make it a > Tier 1 framework. > > Quick Charts is a QML module that implements a set of > high-performance, GPU accelerated > charts. Currently the main user of it is a new KSysGuard UI I have > been working on, but > once it is part of Frameworks I also hope to convert several bits of > Plasma to using it. It has now been a little over two weeks. If there are no objections, I will move this to frameworks later today. Hi Arjen, Did anyone from the Plasma team approve the new KSysGuard UI? It is being developed together with several people from the Plasma team actually. :) It will also go through a separate review, but it needs Quick Charts to be ready before that can happen. - Arjen
Re: Quick Charts in KDE Review
On 21-10-2019 15:22, Arjen Hiemstra wrote: Hi, Quick Charts has been moved to KDE review. The intent is to make it a Tier 1 framework. Quick Charts is a QML module that implements a set of high-performance, GPU accelerated charts. Currently the main user of it is a new KSysGuard UI I have been working on, but once it is part of Frameworks I also hope to convert several bits of Plasma to using it. It has now been a little over two weeks. If there are no objections, I will move this to frameworks later today. - Arjen
Re: Quick Charts in KDE Review
Am Montag, 21. Oktober 2019, 15:22:23 CET schrieb Arjen Hiemstra: > Hi, > > Quick Charts has been moved to KDE review. The intent is to make it a > Tier 1 framework. Any chance the official name can be "KQuickCharts"? "Quick Charts" is a generic name which only asks for being misunderstood, is hard to google etc.. > Quick Charts is a QML module that implements a set of high-performance, > GPU accelerated > charts. Currently the main user of it is a new KSysGuard UI I have been > working on, but > once it is part of Frameworks I also hope to convert several bits of > Plasma to using it. If there is only one user currently, might it perhaps be a better idea to do some independent releases for a while to get more feedback on the API, before settling to the API freeze by being part of KDE Frameworks? It will be at least a year until KF6 is there to properly fix up any potential API inconveniences which users might find. I would at least recommend to first get some API shaping by real-world exposure. Sorry otherwise for not reviewing myself, not into QML the recent months. Cheers Friedrich
Re: Quick Charts in KDE Review
Approved in general, but we will cover that and any ported applets effectively ported from KDeclarative::Plotter in relevant separate review processes. David
Re: Quick Charts in KDE Review
чт, 7 нояб. 2019 г. в 13:53, Arjen Hiemstra : > > On 21-10-2019 15:22, Arjen Hiemstra wrote: > > Hi, > > > > Quick Charts has been moved to KDE review. The intent is to make it a > > Tier 1 framework. > > > > Quick Charts is a QML module that implements a set of > > high-performance, GPU accelerated > > charts. Currently the main user of it is a new KSysGuard UI I have > > been working on, but > > once it is part of Frameworks I also hope to convert several bits of > > Plasma to using it. > > It has now been a little over two weeks. If there are no objections, I > will move this to frameworks later today. Hi Arjen, Did anyone from the Plasma team approve the new KSysGuard UI? -- Alexander Potashev
Re: Quick Charts in KDE Review
On 21-10-2019 15:22, Arjen Hiemstra wrote: Hi, Quick Charts has been moved to KDE review. The intent is to make it a Tier 1 framework. Quick Charts is a QML module that implements a set of high-performance, GPU accelerated charts. Currently the main user of it is a new KSysGuard UI I have been working on, but once it is part of Frameworks I also hope to convert several bits of Plasma to using it. And of course, a link would be useful: https://invent.kde.org/kde/kquickcharts - Arjen
Re: Quick Charts in KDE Review
On 21-10-2019 16:45, Alexander Potashev wrote: Hi Arjen, 1. I don't see any checks in the autotests. Would it be easy to compare the displayed chart against a reference screenshot image, in each of the tests? The same screenshots could also help developers understand what kind of charts kquickcharts is good for. They are very simple QML based tests that currently only verify that the main Chart types still get created correctly. It'd be nice to expand them, though I am slightly hesitant to go with image based tests as they tend to break easily. On the other hand, one of the main reasons for not having more extensive tests is that I did not have an idea on how to do that, and image based tests would solve part of that problem. 2. How to add a grid, ticks and labels to a line chart? For the grid and labels, these are what I generally refer to as "decorations". These are implemented as separate items that you use the normal QML layout options with to layout. You can have a look at controls/LineChartControl.qml to see how it is done for a Line chart. I still need to write some better examples for this, but the control should give you a decent idea. For ticks, assuming with those you mean some marker on the chart data points, these are not currently implemented. I do have some ideas regarding these but I did not need them yet. - Arjen пн, 21 окт. 2019 г. в 16:46, Arjen Hiemstra : On 21-10-2019 15:22, Arjen Hiemstra wrote: > Hi, > > Quick Charts has been moved to KDE review. The intent is to make it a > Tier 1 framework. > > Quick Charts is a QML module that implements a set of > high-performance, GPU accelerated > charts. Currently the main user of it is a new KSysGuard UI I have > been working on, but > once it is part of Frameworks I also hope to convert several bits of > Plasma to using it. And of course, a link would be useful: https://invent.kde.org/kde/kquickcharts > > - Arjen
Quick Charts in KDE Review
Hi, Quick Charts has been moved to KDE review. The intent is to make it a Tier 1 framework. Quick Charts is a QML module that implements a set of high-performance, GPU accelerated charts. Currently the main user of it is a new KSysGuard UI I have been working on, but once it is part of Frameworks I also hope to convert several bits of Plasma to using it. - Arjen
Re: Quick Charts in KDE Review
Hi Arjen, 1. I don't see any checks in the autotests. Would it be easy to compare the displayed chart against a reference screenshot image, in each of the tests? The same screenshots could also help developers understand what kind of charts kquickcharts is good for. 2. How to add a grid, ticks and labels to a line chart? пн, 21 окт. 2019 г. в 16:46, Arjen Hiemstra : > > On 21-10-2019 15:22, Arjen Hiemstra wrote: > > Hi, > > > > Quick Charts has been moved to KDE review. The intent is to make it a > > Tier 1 framework. > > > > Quick Charts is a QML module that implements a set of > > high-performance, GPU accelerated > > charts. Currently the main user of it is a new KSysGuard UI I have > > been working on, but > > once it is part of Frameworks I also hope to convert several bits of > > Plasma to using it. > > And of course, a link would be useful: > > https://invent.kde.org/kde/kquickcharts > > > > > - Arjen -- Alexander Potashev
