Proposal: kde-libs.org, a repository of contributed libraries

[Kevin Krammer]

On Saturday, 2016-06-04, 15:52:17, kdea wrote:
> On Sun May 29 11:17:16 UTC 2016, Kevin Krammer wrote:
> > > They suggested me to upload the library to the "Qt Components" section
> > > of http://qt-apps.org/ , so I did it, and the library is now available
> > > to other developers.
> > 
> > Wouldn't it make much more sense to register it with inqlude.org as a
> > central place for Qt libraries/components instead of spreading over many
> > sites?
> 
> Well, it has been already discussed in the thread. Main points I see are:

Ah, must have missed that.

> * inqlude.org seems to be for big libraries, not for small contributed
>   libraries.

So far only those have registered themselves, I don't see any indication that 
there is a complexity threshold.

> * inqlude.org seems to be only an index, it doesn't store the software (it
>   is not a repository), so developers can't upload the libraries to it, they
> need to upload the libraries to other place and then add the link to the
> index. It means more work for developers.

You mean less work, right?
Uploading to another site is more work than not doing that.

Also, proprietary libraries are not going to upload their code to some random 
site and FOSS libraries that do not have a accessible development 
infrastructure (download, repository, bug tracker, forum/mailingist) are 
probably not something anyone would want to depend on.

> * All of https://www.opendesktop.org/ pages ( http://qt-apps.org/ ,
>   http://kde-apps.org/ , http://kde-look.org/ , http://gtk-apps.org/ , etc )
> share the same structure and behabior, so they are familiar for the
> developers that already have uploaded an app to them.

Sure, but these are for users.
Developers don't just execute libraries or components, they build with them 
and on top of them.

> * Aditionally, developers can (re)use their account in all of the
>   https://www.opendesktop.org/ pages, so no need of extra registrations.

They do hopefully have accounts on their development site.
Or are we primarily talking about code dumps of people who have no interest in 
developing anymore?

> > > Anyway, in the debate at Plasma-devel mailing list, I pointed out two
> > > things:
> > > - Having all types of libraries in one or two sections ("Qt Components"
> > > 
> > >   and "Qt Widgets") is not good, because it will be hard for developers
> > >   to browse/find libraries.
> > 
> > Those should probably filter criteria instead of categories.
> > A developer might be looking for a functional block, or look for
> > something for UI, etc.
> 
> Currently https://www.opendesktop.org/ pages have sections and subsections
> to classify/browse the software (they are on the left column of the pages).
> My proposal reuses the current behabior of those pages, to reduce the
> effort, that's why I propose sections and subsections.

Sections make sense for applications, since applications have specific use 
cases.
They might make sense for libraries if you could categorize them in use cases.
But the proposes sections/subsections didn't even attempt that.

That's like making sections for apps depending on whether they've been written 
with C++ or Python, no matter of what they are doing.
Wouldn't make sense either.
 
> > > For the first solution (add more sections to http://qt-apps.org and
> > > http://kde-apps.org/ ), I would propose the following:
> > > 
> > > - http://qt-apps.org/ :
> > >     - Create a new section "Qt Libraries".  (sections are on the left
> > >     column
> > > 
> > > of the page)
> > > 
> > >     - Create the following subsections under the "Qt Libraries" section:
> > >         Qt 5 C++ libs
> > >         Qt 5 QML libs
> > >         Qt 5 C++/QML libs
> > >         Qt 4 C++ libs
> > >         Qt 4 QML libs
> > >         Qt 4 C++/QML libs
> > 
> > Version should also be a filter criteria instead of a categorie, IMHO.
> > Also why make the language the deciding criteria instead of what the
> > component is for? I.e. is it for UI or is to for networking, etc.
> 
> Well, it is a matter of taste, I prefer to click on "Plasma 5" section, then
> click on "Plasma 5 QML libs", and then I'm sure that all of the libraries
> shown will work with my plasmoid. Certainly, filtering also by version
> could help, but currently https://www.opendesktop.org/ pages don't have
> subsubsections, so the version of the library would have to go in
> subsections, that would multiply the subsections shown, and probably it
> would overload the structure.

So you are trying to shoehorn something into a structure that doesn't make 
sense for libraries?
Like every problem needs to be a nail if all you have is a hammer?

> I made my proposal of sections and subsections based on the language, and
> nobody said anything, but of course it is open to suggestions and
> contributions. So you can make a detailed proposal of sections and
> subsections, if you wish. (if so, please keep it complatible with current
> https://www.opendesktop.org/ pages structure, to reduce the effort).

Well, it makes little sense to have sections that don't give you any 
indication of what is inside.

For example a "Qt5 C++ lib" can basically be about anything.
If a category doesn't allow a meaningful reduction of the set of items to look 
at, it is based on a meaningless criteria.

If you need make sections, it should be something developers are looking for, 
e.g. network service communication, file format handling, UI components, system 
integration, etc.

Anyway, it really matter of what kind of code base we are talking about.

If this is, as I suspect, about code that is abandoned by their developers and 
that they want to dump somewhere in the off chance that somebody might find it 
useful, then creating such a dumping ground might be worthwhile.

If this is about code that is actually being used and maintained, probabably 
even further developed, then it should be handled properly, providing a way 
for other developers to find them, get them, potentially contribute to them.
Like listing them centrally on inqlude.org.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20160606/36145071/attachment.sig>