[kde-edu]: Akademy and Get Hot New Stuff

[Josef Spillner]

Salut,

Alle 20:03, lunedì, 11. settembre 2006, Anne-Marie Mahfouf ha scritto:
> I opened another wiki page about Get Hot New Stuff which KDE-Edu
> applicatins use a lot. I would like to see this dialog fixed a bit so I
> started to list what I don't like and how it could be improved.
> If you have ideas on the matter, please write them down:
> http://wiki.kde.org/tiki-index.php?page=KDE-Edu-Improved+KHotNewStuff+propo
>sal

There are many good tips on that page for developers, but I don't understand 
two of them:

* what is the issue in KAnagram with GHNS? I run it in Italian and get 
the "Italiano" folder with entry names like Valute, Oggetti and Animali, 
which seem to be in the correct category. Should entries of all languages be 
displayed for download at the same time instead?

* the synchronisation with local files: As soon as a file is intended to be 
updated with GHNS later, it should be installed only together with a 
metainformation file. The minimum is a rc file with the version number (let's 
call it version file). Then we need to know how KNS is supposed to find this 
file. In addition to configuring the download path, the app-wide rc file 
needs the path where its data resides. KNS could then scan the data directory 
for version files.
But in order to properly display the data with author etc, the meta.xml file 
for each data file should be used as a version file instead. This is the 
snipped in download.xml for each file. KNS should store them for all 
installed entries for comparison (and get rid of the simple date comparison 
it uses now).
However, then the issue is how do data authors create an initial meta.xml file 
for it? I think a web interface could help. One which only creates the XML 
but does not upload anything. The kdeedu maintainers would then have to check 
that all data packs which are installed by default have a meta.xml file.

An alternative is a script similar to kde-config, let's call it kns-config, 
which uses the KNS mechanism to install a data file only with information 
from the meta.xml file. This forces all data files to have corresponding meta 
information available. Since it would be installed with kdelibs, it would 
always be available. But I don't know how easy it is to write a CMake macro 
for it (although I could do it for automake), because when building kdeedu, 
the install path needs to be taken into account, which is usually not the 
final directory for RPM/Debian packages.

Josef, finally back from his diploma thesis work!