The (unknown) KDE-Platform-independent libraries

[Alexander Neundorf]

On Friday 19 April 2013, John Layt wrote:
> On 5 April 2013 10:12, Lydia Pintscher <lydia at kde.org> wrote:
> > On Fri, Apr 5, 2013 at 10:33 AM, Martin Sandsmark
> > 
> > <martin.sandsmark at kde.org> wrote:
> > > On Thu, Apr 04, 2013 at 11:13:01PM +0200, David Gil Oliva wrote:
> > >> I think that the fact that developers don't use
> > >> KDE-Platform-independent libraries won't cease until something is
> > >> done about the texts of these packages.
> > > 
> > > We don't control those texts, those are written by the Ubuntu packagers
> > 
> > (and
> > 
> > > wikipedia contributors).
> > 
> > David has a point though. And I think it'd be great if we could get
> > some help from him in contacting the people who can change them.
> > 
> > 
> > Cheers
> > Lydia
> 
> The question for me is how many developers would be looking at those as a
> source of information when they go looking for a library to use?  I agree

IMO it's important to get good search (google) results.
I'm always frustrated when I search information about some library (in 
general, not KDE-specific) and what I get is links to some distro package 
pages or mailing list posts.

For kdelibs libraries this is currently not fair, since they (still) do not 
really exist as separate libraries.

I like it when I get the homepage of the library as search result, which 
should contain some description, maybe an example or screenshot, and an 
obvious way how to download releases and current development tree.

I still think enabling the wiki on projects.kde.org would be a very cheap and 
easy way to make that possible for every KDE git repository, without requiring 
the (not always existing) maintainer to additionally maintain a real web page.
(...I would even go so far to use the bug tracker there instead of bugzillla)

> we should make the effort to have them more accurate in their descriptions,
> but I think that's only a small part of the effort required.  Things like
> Qt Dev Days, Qt Centre, and Cornelius' inqlude will be better primary
> targets I feel.  Perhaps it's a topic for QtCS to discuss setting up as
> part of the qt-project.org website a directory of Qt add-on libraries.
> 
> One of the biggest issues we will have to overcome is the whole K-name
> problem where people see it and assume that means it's KDE-only and/or
> bloated.  We'll probably need to develop a consistent marketing and
> branding strategy that emphasises the stand-alone nature of each library in
> Frameworks.  Obviously renaming everything is out-of-the question, but
> we'll need to find a way to describe them that gets the message across,
> e.g. "KArchive, a Qt Add-on by KDE".

Yes.
But maybe this will actually not really be a problem.
If it is easy to find the library as described above, and if it is easy to 
build and use it, maybe there simply will be no hurdle.
I think this will really be vastly different compared to the situation we have 
with kdelibs now.
Building and using the tier1/ libs we have right now is, at least on Linux, 
basically trivial.

Alex