Hi,
let me update some of the points below:
On 03/16/2015 07:16 PM, Bruno Coudoin wrote:
Le 14/03/2015 16:08, Albert Astals Cid a écrit :
El Dissabte, 14 de març de 2015, a les 15:32:55, Bruno Coudoin va escriure:
Le 17/01/2015 00:00, Albert Astals Cid a écrit :
El Dilluns, 12 de gener de 2015, a les 23:58:26, Bruno Coudoin va
escriure:
Hi,
We just made our first official release of GCompris. We now have the
need to maintain a stable and a master version. This is not possible to
do so in playground so it is time for us to go forward and move to
extragear. To this end, we have just moved to kdereview.
I have no idea what the review is looking at so I prepared nothing. If
there something I can do let me know.
Several people pointed you at
https://techbase.kde.org/Policies/Application_Lifecycle which contains a
paragraph tha says "there are some rules to follow before you are allowed
to move to either location:"
We can be lax about some of them, but you should explain why you don't
want to follow them.
Hi,
I am sorry for my late answer, I completely forgot about it.
I copy here the KDE requirements with the answer:
- There should be user documentation in docbook format. If you need
help, you can ask for help to the KDE Documentation team:
kde-doc-engl...@kde.org.
We have 2 types of user documentation:
* inline, each activity has its own documentation easily accessible from
the help menu in GCompris. This is used by children and teacher or
parent to discover what to do in this activity. It is translated through
po files. This proved to be adapted to GCompris use case and I believe
we should keep it this way.
* online manual (http://gcompris.net/wiki/Manual) which is orientated
towards sys admins and advanced school usage (creating profiles,
accessing children logs, ...). This should be moved to docbook. I added
a task in our tracker for that:
http://gcompris.net/wiki/Qt_Quick_Migration_status#Core
Burkhard Lück provided a first version for a docbook based manual based on the online version (now
below docs/docbook/, note, all development takes place on the devel branch currently). This will be
further updated to the QtQuick port.
Although, the main source of documentation will remain the in-app help/manual screens which are part
of the educational concept.
- There should be developers documentation in the form of apidox for
libraries you can check this at ebn
This is something we have not yet investigated but as GCompris matures
it will be more and more needed. The target here is to help activities
developers. I added this need in our task tracker
http://gcompris.net/wiki/Qt_Quick_Migration_status#Core
I added a first version of doxygen/kapidox documentation for most of our core classes and QML
components (under src/core/), which are most important for activity developpers (although we don't
provide a library or QML modules in the strict sense). I followed [1] and had a look at how it is
done in other KDE repos.
GCompris is not yet generated on ebn, is it? Did not find anything at Apidox -> KDE Playground ->
edu. You can find a copy of the generated apidox at [2].
There are still doxygen-warnings which are partly due to component naming or documentation policy.
But will surely be cleaned up more.
Pls let me know if there should be something adjusted to conform to KDE
policies.
- There should be no krazy code checker issues reported. Again, you
can check that at ebn. There is also a tutorial on using Krazy available
here on TechBase.
We did work on that and fixed all the issues on the devel branch. By the
way, EBN must be changed to run krazy with '--check-set qt5' and not
kde4 as it is today.
- If possible, there should have been a basic usability review of your
application. Usability people are hard to get, so this is not crucial.
We would be pleased to get help on that. This is a very important point
for us that we take seriously. So far, as the application has been
released on Android we had the chance to get some user feedback that we
took in account.
- You should have checked for basic problems with a profiler. I hope
we will get a tutorial on how to do this soon
I have already used valgrind on C++ projects but not tested what it
brings to a QML project. We take performance seriously to avoid
excluding schools with limited hardware to run GCompris.
I just did some more checks with valgrind's memcheck, which looked fine.
Most of GCompris code is QML/QtQuick and based on Qt's scene graph. The activities themselves are in
general pretty basic in terms of graphics and effects they use, although this can vary from one
activity to the other. Therefore regarding performance our experience so far is that GCompris run's
as well on a platform as is the GPU support of the underlying platform. The only real issue I saw so
far was on a pretty old desktop PC at Randa which came up without GLX support. Never saw an Android
device having real problems regarding rendering performance so far.
- Your application should be completely translatable.
The translation process is in place and works as expected. We still have
datasets for some activities that should be moved to the po system.
As a side note, you don't ship a .desktop file, which basically makes your
app invisible to desktop menus/launchers.
True, it would be easy to pick the Gtk+ ones but I am not sure how to
make them translatable.
So you can go to google, ask him "kde translate desktop files" that will point
you to
https://techbase.kde.org/Development/Tutorials/Localization/i18n_Build_Systems
and specially
https://techbase.kde.org/Development/Tutorials/Localization/i18n_Build_Systems#Translating_.desktop_Files
Hi,
Thanks for your pointers. I pushed a desktop and an appdata file on the
devel branch.
Bruno.
Pls. let us know if we miss any important points regarding KDE policies/practices/etc. Otherwise we
would be happy if GCompris could be accepted in extragear as we'd really like to switch over to a
release branch git workflow, which would simplify development.
Regards,
Holger
[1] https://techbase.kde.org/Development/Tutorials/API_Documentation
[2] https://www.math.uni-bielefeld.de/~hkaelber/gcompris/apidocs/html/
