> On Nov. 28, 2013, 3:43 p.m., Kevin Ottens wrote:
> > Looks fine to me. Makes me wonder if we want to drop the K for the target 
> > name "KF5::ConfigCore"? Just like Qt5Widgets becomes Qt5::Widgets...
> 
> Martin Klapetek wrote:
>     Can do. Imho it makes sense but I'll wait for some other opinions so I 
> don't have to redo/undo all of it then. Will try to still do it by tonight.
> 
> Martin Klapetek wrote:
>     No comments on dropping the K? I'm about to do this...
> 
> Martin Gräßlin wrote:
>     +1
> 
> Martin Klapetek wrote:
>     While working on it, I realized that it may not be so good to drop the K 
> from target name after all...unless we change the package names too, 
> otherwise we'd be finding package KConfig and linking to KF5::Config, plus 
> all the classes are named KConfig*...so the library in target_link_libs would 
> be quite inconsistent with the rest.
>     
>     Please advise.
> 
> Alex Merry wrote:
>     If we want to follow Qt's example, we would rename the package KF5Config, 
> and leave the classes as KConfig*.  This is a fairly substantial naming 
> change to the packages, though, especially as the consistent thing would be 
> to have KF5Solid and KF5ThreadWeaver, for example.
>     
>     Which I'm generally in favour of, actually.  I'm especially dubious about 
> the names of the ItemModels and ItemViews packages, which are really quite 
> generic.
> 
> Kevin Ottens wrote:
>     Yep, ItemModels and ItemViews would definitely benefit from being 
> prefixed. XmlGui as well... Overall it looks more and more like welcome 
> consistency to me.
> 
> Martin Klapetek wrote:
>     Ok, so to reiterate:
>     
>     lib names -> libKF5Archive, libKF5Config etc (capital F)
>     target names -> KF5::Archive, KF5::Config
>     package names -> KF5Archive, KF5Config
>     
>     correct?
> 
> Kevin Ottens wrote:
>     Works for me if no one has any problem with it.
> 
> Kevin Ottens wrote:
>     Oh, BTW, once we go for it, don't forget to cover plasma-framework too! 
> Probably requires poking on #plasma or plasma-devel, it's kind of an "all or 
> nothing" for the whole KDE Frameworks product.
> 
> David Faure wrote:
>     Looks nice for the examples you gave, but let's take KIO:
>     KIOCore will become lib=libKF5IOCore target=KF5::IOCore in package=KF5IO? 
>  This dilutes the well-known name "KIO"...
>     Maybe in this particular case we want to repeat the K, i.e. 
> libKF5KIOCore, KF5::KIOCore.
>     
>     libKF5Parts also won't look like KParts anymore. Well, I guess that one 
> is a matter of getting used to :)
> 
> Kevin Ottens wrote:
>     I see the point of those two where it's actually part of the brand 
> name... That sais, one could argue it's the same for KConfig or KArchive 
> really... So where is the line?
> 
> David Faure wrote:
>     I think KIO is the special case because it's an acronym. That's where I 
> would draw the line. All others are a meaningful word without the K: Archive, 
> Config, Parts.
>     
>     (IO is kind of meaningful on its own, but KIO isn't just file I/O, as one 
> would think when reading I/O.)
>     
>     Let's not split up acronyms, OTOH splitting up the K from KParts is OK.
>     
>     Oh, and KXmlGui isn't one acronym, it's three, so we can split it up :)
>

It's not even KXmlGui anymore these days I think. ;-)

OK, Martin, let's proceed as you proposed with a single exception: KIO.


- Kevin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/114182/#review44703
-----------------------------------------------------------


On Nov. 28, 2013, 1:46 p.m., Martin Klapetek wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/114182/
> -----------------------------------------------------------
> 
> (Updated Nov. 28, 2013, 1:46 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> -------
> 
> This is just one framework - KConfig - if this is the proper way to do this, 
> I'll update this review with all frameworks updated to this.
> 
> 
> Diffs
> -----
> 
>   tier1/kconfig/autotests/CMakeLists.txt cc2626b 
>   tier1/kconfig/src/core/CMakeLists.txt c8a4842 
>   tier1/kconfig/src/gui/CMakeLists.txt b677d03 
>   tier1/kconfig/src/kconf_update/CMakeLists.txt 69668bc 
> 
> Diff: http://git.reviewboard.kde.org/r/114182/diff/
> 
> 
> Testing
> -------
> 
> Builds.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Reply via email to