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

[Anne-Marie Mahfouf]

Hi Josef,

> There are many good tips on that page for developers,
the main thing is still the server problem
> 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?
yes, because of the purpose of educational software, we need for example 
Italian people being able to play in French.
(side note: because of the server problem, KAnagram files are on a private 
server where only 2 persons have access which poses problem in case the 
server maintainer suddenly disappears.)

I saw that now GHNS is a free-desktop project. Are the issues we raised on the 
wiki page debated in other projects? Is there a mailing list for it?

note: what you could do with automake will certainly be doable with CMake, 
Alex can help and solve any problem I think.

annma
> * 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!
> _______________________________________________
> kde-edu mailing list
> kde-edu at mail.kde.org
> https://mail.kde.org/mailman/listinfo/kde-edu