Proposing Quick Charts as a new framework

[Friedrich W. H. Kossebau]

Am Mittwoch, 18. September 2019, 11:50:58 CEST schrieb Arjen Hiemstra:
> On 09-09-2019 10:24, Dominik Haumann wrote:
> > Hi,
> > 
> > On Sat, Sep 7, 2019 at 3:59 PM Arjen Hiemstra <ahiemstra at heimr.nl>
> > 
> > wrote:
> >> 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:
> > [...]
> > 
> >>>> 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.

When moving away from k-names one still needs to come up with unique 
memorialize names. Which is a challenge.
Using patterns for names, especially when they are for items in a collection, 
helps a lot. Just remember how we like Qt API because almost all methods can 
be guessed from patterns. When using patterns based on generic terms, one 
though also need to think of proper namespacing, to avoid conflicts or 
ambiguity.

Prison, Sonnet, Plasma, Kirigami, Solid, Baloo, Purpose... for each those 
modules you first have to learn what they are about. This can make sense to 
expect for high-profile modules, as they are used often enough, so their names 
will become mapped in brains properly to the functionality the named products 
provide.

But just imagine that all >50 KF modules had such fantasy-born names...

For the others, having a pattern like "K" + english generic description terms 
helps a lot, both in discoverability and understanding the scope. As well as 
attributing the module to be part of "KDE Frameworks". (actually, using "KF" 
as prefix might be even more interesting when it comes to marketing, perhaps 
an idea to pick up starting with the 6 series).

Also, any numbers for versioning should not be part of the basic product name, 
but for products part of a the development series. Like "KDE Frameworks" is 
not named "KDE Frameworks 5" in general, but the "5" only used when denoting 
the current technology series. When people say "KF5", that is a shortcut for 
"technology series 5 of the KDE Frameworks".

Using "Quick Charts" as identifier name would be even more a challenge. 
Somebody hearing/seeing that name would never be able to attribute this to 
anything, unless the context had been properly set up. Just try to query your 
$searchengine for such a name ;) Even in Qt context, there will be always 
doubt if not the QML variant of Qt Charts is meant in an informal descriptive 
way.

So +1 for KQuickCharts, that identifier name would serve lots of purposes (and 
respective repository name)

And yes, there is e.g. the repo name "syntax-highlighting". This was catched 
too late when the module was added to KDE Frameworks, things only got fixed in 
time at least on code level. "Syndication" and modemmanager-qt/networkmanager-
qt/bluez-qt ideally also would be changed to be consistent with the rest. But 
those are exceptions no-one has energy/motivation to fix up now. No reason to 
make life more complicated by new exceptions from rules :)

Other than that:
that library sounds like good work from description, thanks for going to share 
with the world under fair conditions :) (no personal needs currently, so also 
cannot judge about feasibility & overlap with other options)

Cheers
Friedrich