KF5 Update Meeting Minutes 2014-w28

John Layt jlayt at kde.org
Tue Jul 8 18:27:52 BST 2014

On 8 July 2014 16:30, Kevin Ottens <ervin at kde.org> wrote:

>  * he'd like our documentation to improve, we're really behind alternatives in
> that regard;

Seconded, especially from the point-of-view of external devs. For
example, someone today was asking about KArchive and whether it was
fully standalone or depended on external libs that they needed to ship
on non-Linux platforms, but the apidocs don't mention the dependencies
anywhere.  We need to document every single library from the point of
view of someone completely new to KDE who just wants one single
library in their Qt app.

Do we have a single home page or landing point that we want all
potential users to start from?  Do we have general docs to point to
about build chain, licences, getting help, etc?  We have the community
wiki but it is not meant to be for that purpose, and the apidox main
page may be too static to keep up with FAQs, so we probably need to
create some TechBase pages.  Actually, TechBase is really going to
need a big review.

>  * he'd like to see a donation button in KDE apps based on KF5 (developers
> could opt-out);

We already have a link to the donations page buried deep in the "About
KDE" dialog under the "Support KDE" tab where no-one ever sees it.  A
Help menu item for "Donate to KDE..." that pops up a dialog explaining
why would be far more visible, but easily disabled by distros who
object.  We could also include a "Donate to KDE" tip in every
KTipDatabase and ensure it's the first tip shown by default on an apps
first run.  As an admin note, whenever we do add a donate link
anywhere we should make it unique so that we can track how successful
each channel is.

>  * ervin hopes to see kdepimlibs bits getting in sooner rather than later;

I asked on the PIM list the other day, Montel says the plan is not to
start on frameworks until after 4.15, so maybe March/April next year?
I think he meant porting the PIM applications though, so I'm not sure
what that means for starting on pimlibs.  I'll follow up.

My plans:
* Write proper docs for KUnitConversion
* Make KUnitConversion Tier 1 by switching to Qt translations
* In advanced planning for replacements for ISO codes and flag images,
even have some code, see
** OpenCodes: repo of json files of ISO data auto-extracted from
Wikidata, CC-0, can be used by anyone
** KCodes: Qt library which loads OpenCodes files
** OpenFlags: repo of SVG flag images auto-extracted from Wikidata,
with icon set auto-generated from SVGs

Here's a bit of bike-shedding for you: when creating completely new
Frameworks in Tier 1, do we name them with a Q or with a K or with
something completely neutral?



More information about the kde-core-devel mailing list