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 <ahiems...@heimr.nl> > > > > wrote: > >> 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: > > [...] > > > >>>> 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