Re: Naming scheme for Qt5/KF5-based libraries outside of KF5

[Friedrich W. H. Kossebau]

Hi Alexander & all,

thanks for pushing this further.

Am Samstag, 26. September 2015, 18:41:01 schrieb Alexander Potashev:
> Hi everyone,
> 
> We had a little discussion on how to name shared libraries in
> kde-core-devel@ thread "Porting to frameworks 2: libkcompactdisc" [1],
> but we did not come to consensus.
> 
> The question is, if you release a shared library with deps on Qt5
> and/or KF5, but the lib is not part of KF5, how should the .so file be
> named?
> 
> 1. Many people prefer a "KF5" prefix, e.g. libKF5Screen.so).
> 2. Another way of naming is a -qt5 suffix, e.g. libmarblewidget-qt5.so.
> 3. (probably some others?)
> 
> Friedrikh said in [1] that using a KF5 prefix for all libraries will
> "blur the hint by the name if something is part of KF5 or not".

Yes, I still think so:
libQt* is left to Qt libs, and IMHO in the same way should libKF5* be only 
used with real KF5 libs, if that prefix should have a consistent semantic, 
i.e. should say they are part of the KDE Frameworks.

Another reason, though rather less likely:
Even more because someone might start a new lib KF5Foo which they think to be 
become the killer lib for Foo purpose and one day to end up in the KDE 
Frameworks, but then somebody else writes an even better one and that one than 
becomes official KF5 lib for Foo. Would suck if someone occupied the name 
KF5Foo already with an existing lib (as in: released and used by 1-2 apps 
which are fine with the original lib and do not see a need to switch to the 
KF5 one). Better safe than sorry.

WRT to your question on IRC, Alexander:
"
[Samstag, 26. September 2015] [17:32:04 CEST]  frinring_: you are 
saying "it will result in clashes", but that should not be a problem: 
packagers can just forbid parallel installation of the standalone version and 
the new version which is part of KF5
"
which refers to the thread "Porting to frameworks 2: libkcompactdisc" where I 
wrote on 2015-09-04 11:59:57 GMT:
> [...] For once, because it will result in clashes if a lib really
> becomes part of KF5 (and thus becomes part of other packages which might be
> installed together with a package where the lib was initially in, unless the
> lib is the only content of the package, so that can be completely replaced
> by the KF5 package)

Forbidding parallel installation only works if the lib becomes a framework 
without any changes.
Given the high standards and required ABI stability there is a good chance 
that some API brush up (e.g. due to review feedback while proposed as KF5 lib) 
is made before turning into a KF5 lib, as was already pointed out by Sune. 
Having the same name would prevent that (for the usual problems with ABI 
changes).

((I find the "-qt5" postfix sligthly ugly as well, and personally rather use 
postfix integer counters to allow co-installability, but then my libs change 
ABI more often, so just qt version does not work ;) Now, looking at "ls 
/usr/lib64" things get relative, and with cmake config files the lib target 
names used are usually more nice anyway, so "-qt5" should not be such a 
bummer, and besides that this postfix seems to have become a pattern with some 
libs already, so using them would add to consistency.))

My 2 cents.

Cheers
Friedrich

Re: Naming scheme for Qt5/KF5-based libraries outside of KF5

[Boudhayan Gupta]

On 27 September 2015 at 22:51, Sune Vuorela  wrote:
> On 2015-09-27, Boudhayan Gupta  wrote:
>> What I propose is that all libraries which want to manage their own
>> release cycles and their own namespaces, be moved to Extragear Libs
>> and release from there. All the libraries which can stick to the
>> Applications release-unit, move to Support or a new module and be
>> released with them.
>
> What happens if an Applications application uses an extragear lib? or an
> extragear application uses an application lib?
>
> Yes. this will happen.
>
> And then you have a abi/api unstable library out of sync with the
> application it uses. And that's highly annoying.
>
> Seen before with e.g. Digikam/Gwenview/KPhotoAlbum and
> libkipi/libkexiv2/...

"Seen before" is no reason to not move forward if we can actually fix
this. As I said, Extragear library developers will *have* to provide
API/ABI guarantees.

> I don't see why we need a extra organizational level to house something
> we should try to avoid to have in the fist place.
>
> Let's get all good libraries made frameworks.

That's the ideal scenario, but isn't becoming a framework... hard?

Cheers,
Boudhayan

Re: Adding further modules to api.kde.org

[Alex Merry]

On 2015-09-19 18:11, Allen Winter wrote:

On Saturday, September 19, 2015 07:03:40 PM Martin Graesslin wrote:

On Saturday, September 19, 2015 12:54:57 PM CEST you wrote:
> http://api.kde.org/4.x-api/workspace-apidocs/kwayland/html/index.html
> look ok?

hmm that doesn't use the wonderful README.md. Compare to 
http://kde.martin-graesslin.com/kwayland/index.html (requires IPV6)


Interestingly whenever I locally generated with kgenapidox it included 
the
README.md and I did verify after adding the .dox file that it doesn't 
change.

What's used on ebn to generate the docs?


Ancient scripts that predate kgenapidox by at least a decade.
I wonder if symlinking Mainpage.dox to README.md would work for now.
I'll try that


Ideally, I'd like it set up so we can move to everyone using the kapidox 
scripts, but we need some way of switching that on per-repository (like 
having a Mainpage.dox does with the old scripts). My understanding is 
that there is code that runs kgenframeworksapidox on the frameworks 
explicitly, and everything else uses the old scripts.


Alex

Re: Naming scheme for Qt5/KF5-based libraries outside of KF5

[Friedrich W. H. Kossebau]

Hi Boudhayan,

Am Sonntag, 27. September 2015, 04:01:26 schrieb Boudhayan Gupta:
> We could kill two birds with one stone here, creating a new KDE module
> just for libraries (say, KDE Companion Libraries or something) and put
> everything in the KC5 (or whatever we decide) namespace.
> 
> I'm all for just putting everything in KDE Support, using the KS5
> namespace and removing the tier0 restriction from Support.

Some bummer here:
a) not all libraries are in repositories of their own
b) not all libraries are released on the same cycle

E.g. a) happens because the libs could be shared libs for sharing between 
multiple executables/plugins developed in a single repo. Or they are only 
slowly established as shared code and still developed strongly coupled with 
their main user executable/plugin and for that live in the same repo.
And b) is because there are a few libs in extragear or playground repos, so 
not covered by the "KDE Applications" release cycle or forced to follow.

So while I agree that having all libs nicely separated would be good to have, 
if only for discoverability, doing that with a single module at least 
currently would not work.

((Long-term we should perhaps look into that, because right now the layout of 
our repository structure does not make a difference between repos with 
executables, plugins and libraries (and mixed ones).
And IMHO if we have libs, thus code intended to be shared between other 
software, it would be great if it would be easy to developers to simply browse 
all of the libs to find something perhaps matching. If that list would be a 
virtual one, fine as well, but having the real repositories ordering also 
follow that grouping helps shaping minds and reduces complexicity needed due 
to the mapping.
(Would also make it simpler to know which libs there are that should be also 
noted at inqlude.org)

But different topic, with quite some details and strings attached, worth at 
least a different thread (and someone who can and would drive any planning for 
that for some time, not me).))

Cheers
Friedrich

Re: Naming scheme for Qt5/KF5-based libraries outside of KF5

[Boudhayan Gupta]

Hi Friedrich,

On 27 September 2015 at 20:55, Friedrich W. H. Kossebau
 wrote:
> Some bummer here:
> a) not all libraries are in repositories of their own
> b) not all libraries are released on the same cycle
>
> E.g. a) happens because the libs could be shared libs for sharing between
> multiple executables/plugins developed in a single repo. Or they are only
> slowly established as shared code and still developed strongly coupled with
> their main user executable/plugin and for that live in the same repo.
> And b) is because there are a few libs in extragear or playground repos, so
> not covered by the "KDE Applications" release cycle or forced to follow.

So let's clean this mess up.

For applications, Extragear seems to be the place to live in if you
manage your own release cycles. I see no reason libraries should also
be treated the same way.

What I propose is that all libraries which want to manage their own
release cycles and their own namespaces, be moved to Extragear Libs
and release from there. All the libraries which can stick to the
Applications release-unit, move to Support or a new module and be
released with them.

This has the advantage of Application libs not having to maintain
API/ABI stability, since the Applications from one release will depend
on the libs from the same release. Extragear Libs devs, who want to
manage their own cycles etc, will however have to make API/ABI
guarantees.

Also, I get the feeling that Extragear is treated as a second-class
citizen. It doesn't have to be. Apps and libs in Extragear should be
held to the same standards as the rest of the KDE modules. The only
difference ever should be the release cycles.

> So while I agree that having all libs nicely separated would be good to have,
> if only for discoverability, doing that with a single module at least
> currently would not work.

Can you elaborate on why a single module would not work?

> ((Long-term we should perhaps look into that, because right now the layout of
> our repository structure does not make a difference between repos with
> executables, plugins and libraries (and mixed ones).
> And IMHO if we have libs, thus code intended to be shared between other
> software, it would be great if it would be easy to developers to simply browse
> all of the libs to find something perhaps matching. If that list would be a
> virtual one, fine as well, but having the real repositories ordering also
> follow that grouping helps shaping minds and reduces complexicity needed due
> to the mapping.
> (Would also make it simpler to know which libs there are that should be also
> noted at inqlude.org)

+1

Side note here - I'm very interested in getting Vlc-Qt under the KDE
umbrella, if the maintainers of Vlc-Qt and KDE are in support. A
dedicated library module would be a great place for it.

> But different topic, with quite some details and strings attached, worth at
> least a different thread (and someone who can and would drive any planning for
> that for some time, not me).))

I'd love to help. I love organization ;-)

Cheers,
Boudhayan.

Re: Spectacle moved to KDE Graphics, future of KSnapshot?

[Boudhayan Gupta]

On 27 September 2015 at 20:35, Thomas Lübking  wrote:
> On Samstag, 26. September 2015 11:05:25 CEST, Boudhayan Gupta wrote:
>>
>> On 26 September 2015 at 06:55, Eike Hein  wrote:
>>>
>>> I'm more concerned about the migration path from KSnapshot
>>> to Spectacle. Can we make a hard decision to abandon
>>> KSnapshot on X11
>>
>>
>> +1
>>
>>> and have Spectacle install a ksnapshot
>>> symlink for a grace period?
>>
>>
>> -1
>
>
>
> One hardly makes sense without the other.
> As of today there'll be many installations with (hand- or distromade) global
> shortcuts calling "ksnapshot -something" on Ctrl/Alt/Meta+Print - if we tell
> distros to abandon ksnapshot, the result will be a hell lot of systems w/o
> working printscreen functionality. "Supergreat".
>
> I'd prefer to see a symlink or shim (wrapping ksnapshot switches to
> "spectacle" (wtf came up with that name? ;-) ones), but if there's no
> migration path, ksnapshot "needs" to remain and users have to choose the
> upgrade to "spectacle".

The shim is a good idea. Anybody up for writing one (I'm not too good
at shell, unfortunately).

Cheers,
Boudhayan

Re: Naming scheme for Qt5/KF5-based libraries outside of KF5

[Thomas Lübking]

On Sonntag, 27. September 2015 16:48:03 CEST, Friedrich W. H. Kossebau wrote:


Yes, I still think so:
libQt* is left to Qt libs, and IMHO in the same way should libKF5* be only 
used with real KF5 libs, if that prefix should have a consistent semantic, 
i.e. should say they are part of the KDE Frameworks.


+1

((I find the "-qt5" postfix sligthly ugly as well, and 



libKX5Foo - "kde eXperimental" or "kde eXtension" rather than "kde frameworks"?

Cheers,
Thomas

Re: Spectacle moved to KDE Graphics, future of KSnapshot?

[Boudhayan Gupta]

On 27 September 2015 at 23:43, Elias Probst  wrote:
>
>
>
> On September 27, 2015 6:50:19 PM GMT+02:00, Boudhayan Gupta  
> wrote:
>
>>The shim is a good idea. Anybody up for writing one (I'm not too good
>>at shell, unfortunately).
>
> What about a slim C++/Qt shim? A shell shim would be non-portable.

So would a C++/Qt solution (execve isn't available on Windows). An
API-level frontend is possible, but's like a different main(), a
different QApplication - the whole shebang. And remember, not
implementing the KSnapshot DBus API, because it doesn't map at all to
Spectacle's internals.

We shouldn't try too hard to look like KSnapshot. Shell will work on
Linux, which is the only platform for which there's a backend ATM. It
will also work on OSX. It won't work on Windows, but Windows people
have "Shortcuts" and other fancy stuff.

-- Boudhayan

Re: Spectacle moved to KDE Graphics, future of KSnapshot?

[Ivan Čukić]

Is there any reason for not changing the command line arguments of
Spectacle to fit KSnapshot? It is not like anyone is used to them yet.

Cheers,
Ivan

--
KDE, ivan.cu...@kde.org, http://cukic.co/
gpg key id: 850B6F76

Re: Naming scheme for Qt5/KF5-based libraries outside of KF5

[Alexander Potashev]

2015-09-27 21:05 GMT+03:00 Sune Vuorela :
> On 2015-09-27, Boudhayan Gupta  wrote:
>> "Seen before" is no reason to not move forward if we can actually fix
>> this. As I said, Extragear library developers will *have* to provide
>> API/ABI guarantees.
>
> Good luck with that.
>
>> That's the ideal scenario, but isn't becoming a framework... hard?
>
> No. Once you have something useful, reviewed and wants to commit to
> abi/api stability it is just a bit of paperwork.

Sune,

One does not simply commit to ABI/API stability. Look at kmime, kmbox,
etc: KDE PIM team was about to submit these libraries into KF5, but
now they have to bump SOVERSIONs [1] because of breaking ABI.

And you can also look at the numbers: KF5 grows at the rate of less
than one framework per month. We probably don't have enough manpower
to review dozens/hundreds of libraries in a short period of time.

[1] https://git.reviewboard.kde.org/r/125285/

-- 
Alexander Potashev

Re: Spectacle moved to KDE Graphics, future of KSnapshot?

[Thomas Lübking]

On Sonntag, 27. September 2015 20:32:28 CEST, Ivan Čukić wrote:

Hi,

Which cmd line options are available in KSnapshot and not in
Spectacle? Is it only --freeregion and --child?


 -m, --currentCapture the current monitor
 -a, --activewindow   Capture the active window
 -u, --windowundercursor  Capture the window currently under the cursor,
  including parents of pop-up menus
 -t, --transientonly  Capture the window currently under the cursor,
  excluding parents of pop-up menus
 -c, --clipboard  In background mode, send image to clipboard without
  saving to file

vs.

 -c, --current Captures the window under the mouse on startup

=> "-c" => "-t" and "--current" => "--transientonly"

Cheers,
Thomas

Re: Spectacle moved to KDE Graphics, future of KSnapshot?

[Boudhayan Gupta]

On 28 September 2015 at 02:00, Ivan Čukić  wrote:
> Is there any reason for not changing the command line arguments of
> Spectacle to fit KSnapshot? It is not like anyone is used to them yet.

KSnapshot is actually two programs, ksnapshot and kbackground snapshot
(there's a third program too, in the kdelibs4 builds). Spectacle is
one, with all the features rolled in there. I thought since this is
all new, might as well start from scratch with the command line args
too.

I'm averse to changing them to match ksnapshot though. Firstly, some
modes don't exist. Secondly, one (Window Under Cursor) has different
behaviour in Spectacle. I'd rather there was a one-time rude shock to
the user over silently using scripts he's written for months before
realising, oops, this is not the picture I wanted.

-- Boudhayan.

Re: Naming scheme for Qt5/KF5-based libraries outside of KF5

[Alexander Neundorf]

On Sunday, September 27, 2015 17:21:04 Sune Vuorela wrote:
> On 2015-09-27, Boudhayan Gupta  wrote:
> > What I propose is that all libraries which want to manage their own
> > release cycles and their own namespaces, be moved to Extragear Libs
> > and release from there. All the libraries which can stick to the
> > Applications release-unit, move to Support or a new module and be
> > released with them.
> 
> What happens if an Applications application uses an extragear lib? or an
> extragear application uses an application lib?
> 
> Yes. this will happen.
> 
> And then you have a abi/api unstable library out of sync with the
> application it uses. And that's highly annoying.
> 
> Seen before with e.g. Digikam/Gwenview/KPhotoAlbum and
> libkipi/libkexiv2/...
> 
> 
> I don't see why we need a extra organizational level to house something
> we should try to avoid to have in the fist place.
> 
> Let's get all good libraries made frameworks.


+1

Alex

Re: Naming scheme for Qt5/KF5-based libraries outside of KF5

[Kevin Kofler]

Friedrich W. H. Kossebau wrote:
> Given the high standards and required ABI stability there is a good chance
> that some API brush up (e.g. due to review feedback while proposed as KF5
> lib) is made before turning into a KF5 lib, as was already pointed out by
> Sune. Having the same name would prevent that (for the usual problems with
> ABI changes).

Not if you ship your not-yet-in-KF5 library with a soversion (soname major 
version) < 5. (I'd just pick 0.)

Kevin Kofler

Re: Spectacle moved to KDE Graphics, future of KSnapshot?

[Thomas Lübking]

On Samstag, 26. September 2015 11:05:25 CEST, Boudhayan Gupta wrote:

On 26 September 2015 at 06:55, Eike Hein  wrote:

I'm more concerned about the migration path from KSnapshot
to Spectacle. Can we make a hard decision to abandon
KSnapshot on X11


+1


and have Spectacle install a ksnapshot
symlink for a grace period?


-1



One hardly makes sense without the other.
As of today there'll be many installations with (hand- or distromade) global shortcuts calling 
"ksnapshot -something" on Ctrl/Alt/Meta+Print - if we tell distros to abandon ksnapshot, 
the result will be a hell lot of systems w/o working printscreen functionality. 
"Supergreat".

I'd prefer to see a symlink or shim (wrapping ksnapshot switches to "spectacle" (wtf came up with 
that name? ;-) ones), but if there's no migration path, ksnapshot "needs" to remain and users have 
to choose the upgrade to "spectacle".

Cheers,
Thomas

Re: Naming scheme for Qt5/KF5-based libraries outside of KF5

[Sune Vuorela]

On 2015-09-27, Boudhayan Gupta  wrote:
> "Seen before" is no reason to not move forward if we can actually fix
> this. As I said, Extragear library developers will *have* to provide
> API/ABI guarantees.

Good luck with that.

> That's the ideal scenario, but isn't becoming a framework... hard?

No. Once you have something useful, reviewed and wants to commit to
abi/api stability it is just a bit of paperwork.

/Sune

Re: Spectacle moved to KDE Graphics, future of KSnapshot?

[Ivan Čukić]

Hi,

Which cmd line options are available in KSnapshot and not in
Spectacle? Is it only --freeregion and --child?

If those are not supported by Spectacle, a shim (as opposed to a
symlink) would not help much IMO. I don't see what a shim would be
able to do when passed those arguments if the receiving application
does not support the requested feature.

Cheerio,
Ivan

--
KDE, ivan.cu...@kde.org, http://cukic.co/
gpg key id: 850B6F76

Re: Naming scheme for Qt5/KF5-based libraries outside of KF5

[Sune Vuorela]

On 2015-09-27, Boudhayan Gupta  wrote:
> What I propose is that all libraries which want to manage their own
> release cycles and their own namespaces, be moved to Extragear Libs
> and release from there. All the libraries which can stick to the
> Applications release-unit, move to Support or a new module and be
> released with them.

What happens if an Applications application uses an extragear lib? or an
extragear application uses an application lib?

Yes. this will happen.

And then you have a abi/api unstable library out of sync with the
application it uses. And that's highly annoying.

Seen before with e.g. Digikam/Gwenview/KPhotoAlbum and
libkipi/libkexiv2/...


I don't see why we need a extra organizational level to house something
we should try to avoid to have in the fist place.

Let's get all good libraries made frameworks.

/Sune

Re: Cervisia?

[Michael Reeves]

On Sep 26, 2015 9:22 PM, "Jeremy Whiting"  wrote:
>
> Martin,
>
> Michael Reeves reeves...@gmail.com mentioned he would be interested in
> helping also, maybe the two of you can get it ported away from
> Qt3Support, then ported to Qt5/Kf5 ?
>
> thanks,
> Jeremy
>
Sounds like a plan. I don't have write access to the repo. I too have
limited time.

Re: Naming scheme for Qt5/KF5-based libraries outside of KF5

[Kevin Kofler]

Sune Vuorela wrote:
> I do think that having things named KF5 that aren't actual frameworks is
> bad for several reasons.
> 
> 1) It blurs what's a framework

That's more a political distinction than a technical one. For all practical 
purposes, the application using the library doesn't care whether it is a 
"Framework" or not.

> 2) We promise ABI and API compatibility for frameworks, but not for
> other things

But it means you will gratuitously break both source (!) and binary 
compatibility for all users of the library when the library actually becomes 
a Framework.

> 3) Moving something from "not a KDE Framework" to "KDE Framework" gives
> a last chance for fixing up abi/api.

If you need to fix the ABI, you should just bump the soname major version.

I'd just use libKF5*.so.0 (instead of the normal .5) for libraries that are 
not yet Frameworks.

Kevin Kofler

Re: Naming scheme for Qt5/KF5-based libraries outside of KF5

[Boudhayan Gupta]

On 27 September 2015 at 10:29, Alexander Potashev  wrote:
> 2015-09-27 1:39 GMT+03:00 Albert Astals Cid :
>> El Diumenge, 27 de setembre de 2015, a les 04:01:26, Boudhayan Gupta va
>> escriure:
>>> On 27 September 2015 at 03:36, Albert Astals Cid  wrote:
>>> > El Dissabte, 26 de setembre de 2015, a les 16:27:22, Sune Vuorela va
>> escriure:
>>> >> On 2015-09-26, Alexander Potashev  wrote:
>>> >> > 1. Many people prefer a "KF5" prefix, e.g. libKF5Screen.so).
>>> >> > 2. Another way of naming is a -qt5 suffix, e.g. libmarblewidget-qt5.so.
>>> >> > 3. (probably some others?)
>>> >> >
>>> >> > Friedrikh said in [1] that using a KF5 prefix for all libraries will
>>> >> > "blur the hint by the name if something is part of KF5 or not".
>>> >> >
>>> >> > Any thoughts? I believe we can have guidelines for library names.
>>> >>
>>> >> I do think that having things named KF5 that aren't actual frameworks is
>>> >> bad for several reasons.
>>> >>
>>> >> 1) It blurs what's a framework
>>> >> 2) We promise ABI and API compatibility for frameworks, but not for
>>> >> other things
>>> >> 3) Moving something from "not a KDE Framework" to "KDE Framework" gives
>>> >> a last chance for fixing up abi/api.
>>> >>
>>> >> so. foo-qt5 is fine for a qt5 version of foo.
>>> >
>>> > I agree, the problem is that there's few exceptions to copy from, so
>>> > that's
>>> > the exact reason libkdegames has that KF5 thing in the name, the guy that
>>> > did the port just copied what the frmeworks do.
>>> >
>>> > So anyone up for write what "a library that is not frameworks should do to
>>> > be nice in the KDE land"?
>>>
>>> We could kill two birds with one stone here, creating a new KDE module
>>> just for libraries (say, KDE Companion Libraries or something) and put
>>> everything in the KC5 (or whatever we decide) namespace.
>>>
>>> I'm all for just putting everything in KDE Support, using the KS5
>>> namespace and removing the tier0 restriction from Support.
>>
>> I don't see which birds it kills, as far as I see it it only gives you the
>> problem of having yet another product to release.
>
> Sune, Boudhayan, Albert,
>
> Thanks for your feedback! I think we already have consensus on the
> "-qt5" suffix. I'll go rename the shared libraries in a few repos...
> :)
>
> Albert, do you mean you want a Techbase page with guidelines for libraries?
>
> Regarding the library product, Boudhayan almost repeated my proposal
> [1]. But using a namespace (e.g. KC5::) would not be a good idea
> because this product may contain completely disconnected libraries.
> "-qt5" suffixes should be enough. For KF5 the namespace makes sense
> because the frameworks have numerous dependencies between one another,
> thus KF5 feels and is promoted as an all-in-one product.
>
> [1] https://mail.kde.org/pipermail/release-team/2015-June/008628.html

Putting hyphens in library names is just ugly, when the rest of the
product name is neat and tidy CamelCase with an initial uppercase
letter.

I'm still in favour of a new product, or reusing KDESupport, or even
Extragear libs. If you must use a suffix though, please consider using
Qt5, not -qt5, so that the lib becomes libSomeThingQt5, not
libSomeThing-qt5.

-- Boudhayan

Re: Naming scheme for Qt5/KF5-based libraries outside of KF5

[Alexander Potashev]

2015-09-27 12:42 GMT+03:00 Boudhayan Gupta :
> I'm still in favour of a new product, or reusing KDESupport, or even
> Extragear libs. If you must use a suffix though, please consider using
> Qt5, not -qt5, so that the lib becomes libSomeThingQt5, not
> libSomeThing-qt5.

Boudhayan,

Camel case naming rule applies only to the frameworks already in KF5.
If your library is not part of KF5, then you can name it in lowercase:
libkcompactdisc-qt5, and the dash doesn't look ugly here IMO.

-- 
Alexander Potashev

Re: Naming scheme for Qt5/KF5-based libraries outside of KF5

[Sune Vuorela]

On 2015-09-26, Boudhayan Gupta  wrote:
> We could kill two birds with one stone here, creating a new KDE module
> just for libraries (say, KDE Companion Libraries or something) and put
> everything in the KC5 (or whatever we decide) namespace.

By doing this, we kind of make it a thing to .. become. I do think that
shared cross-repository libraries that aren't frameworks should be
avoided as much as possible, and for the few ones where it isn't
possible for specific functionality we should still try to limit it.

It is libraries that might change abi and api, and that's generally a
mess, especially if the users have different release schedules. And
people will use an available shared library.

> I'm all for just putting everything in KDE Support, using the KS5
> namespace and removing the tier0 restriction from Support.

KDE Support is our 'low level' libraries, but many of them has become
frameworks, which I think should also be the road ahead.

/Sune

Re: Naming scheme for Qt5/KF5-based libraries outside of KF5

[Boudhayan Gupta]

On 27 September 2015 at 15:29, Sune Vuorela  wrote:
> On 2015-09-26, Boudhayan Gupta  wrote:
>> We could kill two birds with one stone here, creating a new KDE module
>> just for libraries (say, KDE Companion Libraries or something) and put
>> everything in the KC5 (or whatever we decide) namespace.
>
> By doing this, we kind of make it a thing to .. become. I do think that
> shared cross-repository libraries that aren't frameworks should be
> avoided as much as possible, and for the few ones where it isn't
> possible for specific functionality we should still try to limit it.

What exactly is wrong with shared cross-repo libraries? Take
libPurpose for example. It's a great little utility that many apps can
use, but it's certainly not mature enough to be a framework. I'd want
it in a place where many people can use it.

> It is libraries that might change abi and api, and that's generally a
> mess, especially if the users have different release schedules. And
> people will use an available shared library.

What's wrong with people using a shared library? That's what they're for.

A new component must be aligned with the Applications release-unit,
and since Applications are primary (only?) users of the libraries, and
API/ABI break shouldn't cause any problems at all, given that apps in
the (eg) 15.12 release will only depend on the 15.12 version of the
library.

Also, why are we assuming API/ABI will be broken? Can't developers be
trusted to be strict with their APIs?

>> I'm all for just putting everything in KDE Support, using the KS5
>> namespace and removing the tier0 restriction from Support.
>
> KDE Support is our 'low level' libraries, but many of them has become
> frameworks, which I think should also be the road ahead.

Again, if it can become a framework, make it a framework. If it can't,
put it in Support and release it with Applications.

>
> /Sune

Cheers,
Boudhayan