RFC: On-demand package installation API in kdelibs

[John Layt]

On Wednesday 28 July 2010 20:10:12 Lubos Lunak wrote:
> On Wednesday 28 of
July 2010, John Layt wrote:
> > There's a long-standing wish in bko to allow
users to install
> > KDE translations from the locale kcm, i.e. a big button
in the Languages
> > tab saying "Install More Translations".  I'm currently
re-writing the kcm
> > and was just about to ask around on opinions about
it.
> > 
> > The Spell Checker kcm
> > could also do with an "Install More
Dictionaries" button.
> > 
> > For this purpose
> > any such api would need
to be able to queried for a list of language
> > codes for available
translations or dictionaries to show the user, and
> > then take a given
language code and try to install the translation or
> > dictionary.
> 
>  I
haven't thought of adding calls for querying what capabilities are
>
available, my first idea here would be to simply try to do
> e.g.
'installCapability( "kde-translations-cz" )'. That should take care
> of
"Install More Translations" (if that means "more for this language").
> 
> 
What would you need the querying for? Would it be for "more translations"
>
== "more languages"? Querying could be added, so that you could
> do
'queryCapability( "kde-translation" )' and it'd
> give "kde-translation-cz",
"kde-translation-de" etc., but I expect you
> might have a small problem
with getting "Czech", "German" out of that. You
> generally cannot get all
info about a package without installing it first,
> so all this would need
to be stuffed into packages' capabilities (e.g.
> rpm's 'provides'). What
would be your requirements here exactly?
> 

Sorry, I'll use "Languages"
rather than "Translations" here.  I've just been messing with the kcm
labelling to see if Translations would make more sense to users, they
apparently don't understand what we mean by Languages.

I specifically mean
the packages named in openSUSE like "kde4-l10n-en_GB" that provide the KDE
.mo translation files, docbooks, etc for each language.  The ISO language
code on the end would be what I would want to use in the API, each distro
should know how to convert that into their own package name format, and we
already know how to convert it into a localised name using
KLocale::languageCodeToName().  Parsing the language code out of the package
name is probably the simplest way, but I guess the package could provide a
'provides' key of some kind, but that's a distro level implementation
issue.

In the Locale KCM in the Languages tab the user can select from a
list of the currently installed KDE languages those languages they want to
be searched for translations in the order of priority.  It's probably not a
common scenario, but if a user wanted to install other languages we
could:
1) enable the Install button only if the api says the facility is
available
2) list the languages that the api says are available to be
installed
3) return if the install was successful so the kcm knows to add
the language to the installed list

Apps that are outside the core KDE
modules, such as KOffice and ExtraGear, are not included in those
kde4-l10n-* packages, so they could provide a button for "Install
Application Language" in the "Switch Application Language" dialog from the
help menu.  Well, we could do that for all apps anyway, we'd just need a way
of knowing which package to install for which app.

The Spelling
Dictionaries would be a far more common scenario, e.g. for multilingual
users.  We could expose this anywhere you spellcheck.  It's certainly more
user friendly than saying "Run Yast and install aspell-fr"

These could be
special cases in the api, rather than generic calls:

    bool
canInstallLanguages(appName)
    QStringList availableLanguages(appName)
   
bool installLanguage(languageCode, appName)

    bool
canInstallDictionaries()
    QStringList availableDictionaries()
    bool
installDictionary(languageCode)

If it was a generic installCapability(
"kde-language-fr" ) then we would just be doing lots of parsing of the key
at both ends to obtain the language code and decide what to do.

John.