Re: GCompris in kdereview
El Diumenge, 5 d'abril de 2015, a les 12:11:17, Bruno Coudoin va escriure: > Le 30/03/2015 22:38, Albert Astals Cid a écrit : > > Moving to extragear is fine for me. (let's give some time for others to > > voice their opinion) > > Hi, > > Any news on this? I guess you can understand this is a silent approval. Cheers, Albert > > Bruno.
Re: GCompris in kdereview
Le 30/03/2015 22:38, Albert Astals Cid a écrit : > Moving to extragear is fine for me. (let's give some time for others to voice > their opinion) Hi, Any news on this? Bruno.
Re: GCompris in kdereview
El Dilluns, 30 de març de 2015, a les 01:35:11, Bruno Coudoin va escriure: > Le 30/03/2015 01:22, Albert Astals Cid a écrit : > > El Dilluns, 30 de març de 2015, a les 01:18:16, Bruno Coudoin va escriure: > >> Le 30/03/2015 00:37, Albert Astals Cid a écrit : > >>> El Dimecres, 25 de març de 2015, a les 23:03:21, Holger Kaelberer va > > > > escriure: > Hi, > > let me update some of the points below: > > 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. > >>> > >>> There's still no .desktop file, as said, i'd really appreciate one. > >> > >> Hi, > >> > >> It there but in the devel branch: > >> http://quickgit.kde.org/?p=gcompris.git&a=tree&hb=87345383efae7d7b30c03ea > >> 64b c03f0db37d4d2b > > > > Well, you should really have mentioned we had to look at another branch > > than master, master is the branch we usually look at when reviews are > > asked. > I already mentioned that the 16th of march on this list: "Thanks for > your pointers. I pushed a desktop and an appdata file on the > devel branch." Right, sorry, missed that. > > > How different is that devel branch from master? > > As we cannot have a translated stable branch and we need to maintain the > published android version, we had no choice and made our master branch > the stable branch. You could have just pointed your trunk i18n branch to a a branch different than master branch as well. > > All the developments are done in the devel branch, including the > documentation efforts. Ok, i don't have time to review the ~150 changes that went into that branch, let's assume you fixed everything i wanted and didn't introduce anything bad :) Moving to extragear is fine for me. (let's give some time for others to voice their opinion) Cheers, Albert > > Bruno.
Re: GCompris in kdereview
Le 30/03/2015 12:06, Luigi Toscano a écrit : > On Monday 30 of March 2015 11:56:13 Luca Beltrame wrote: >> Bruno Coudoin wrote: >>> As we cannot have a translated stable branch and we need to >> Perhaps naive question: why? > I think temporarily as they are in kdereview. We never had a stable branch > for > kdereview, maybe because it was meant for applications moving from the "new > program with no regular releases" to "regular releases, either in SC or on > their own in extragear". > > If this is true, now we have a kitchen and egg problem :) > > Question for GCompris developers: do you plan to stop working on the current > stable branch (master), which means no releases from it, and merging devel > into it, soon? This would solve the problem (up-to-date translatable master, > end of review, move to extragear, regular releases, stable translation > branch, > profit). Hi, Yes, our goal is to create a stable branch from our master and merge our devel branch in master. We will do this as soon as we are accepted in extragear. So if you need this merge before accepting us, we need to put a mutex somewhere to get out of this dead lock. Bruno.
Re: GCompris in kdereview
On Monday 30 of March 2015 11:56:13 Luca Beltrame wrote: > Bruno Coudoin wrote: > > As we cannot have a translated stable branch and we need to > > Perhaps naive question: why? I think temporarily as they are in kdereview. We never had a stable branch for kdereview, maybe because it was meant for applications moving from the "new program with no regular releases" to "regular releases, either in SC or on their own in extragear". If this is true, now we have a kitchen and egg problem :) Question for GCompris developers: do you plan to stop working on the current stable branch (master), which means no releases from it, and merging devel into it, soon? This would solve the problem (up-to-date translatable master, end of review, move to extragear, regular releases, stable translation branch, profit). Ciao -- Luigi
Re: GCompris in kdereview
Bruno Coudoin wrote: > As we cannot have a translated stable branch and we need to Perhaps naive question: why? -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
Re: GCompris in kdereview
Hi, it is present in devel branch which is the actual development branch: http://quickgit.kde.org/?p=gcompris.git&a=blob&h=b7925b6c1a514afac8de9c9c1a2615488fe9b3a0&hb=87345383efae7d7b30c03ea64bc03f0db37d4d2b&f=org.kde.gcompris.desktop Johnny On 03/30/15 00:37, Albert Astals Cid wrote: El Dimecres, 25 de març de 2015, a les 23:03:21, Holger Kaelberer va escriure: Hi, let me update some of the points below: 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. There's still no .desktop file, as said, i'd really appreciate one. Cheers, Albert Regards, Holger [1] https://techbase.kde.org/Development/Tutorials/API_Documentation [2] https://www.math.uni-bielefeld.de/~hkaelber/gcompris/apidocs/html/
Re: GCompris in kdereview
Le 30/03/2015 01:22, Albert Astals Cid a écrit : > El Dilluns, 30 de març de 2015, a les 01:18:16, Bruno Coudoin va escriure: >> Le 30/03/2015 00:37, Albert Astals Cid a écrit : >>> El Dimecres, 25 de març de 2015, a les 23:03:21, Holger Kaelberer va > escriure: Hi, let me update some of the points below: 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. >>> There's still no .desktop file, as said, i'd really appreciate one. >> Hi, >> >> It there but in the devel branch: >> http://quickgit.kde.org/?p=gcompris.git&a=tree&hb=87345383efae7d7b30c03ea64b >> c03f0db37d4d2b > Well, you should really have mentioned we had to look at another branch than > master, master is the branch we usually look at when reviews are asked. I already mentioned that the 16th of march on this list: "Thanks for your pointers. I pushed a desktop and an appdata file on the devel branch." > How different is that devel branch from master? As we cannot have a translated stable branch and we need to maintain the published android version, we had no choice and made our master branch the stable branch. All the developments are done in the devel branch, including the documentation efforts. Bruno.
Re: GCompris in kdereview
El Dilluns, 30 de març de 2015, a les 01:18:16, Bruno Coudoin va escriure: > Le 30/03/2015 00:37, Albert Astals Cid a écrit : > > El Dimecres, 25 de març de 2015, a les 23:03:21, Holger Kaelberer va escriure: > >> Hi, > >> > >> let me update some of the points below: > >> > >> 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. > > > > There's still no .desktop file, as said, i'd really appreciate one. > > Hi, > > It there but in the devel branch: > http://quickgit.kde.org/?p=gcompris.git&a=tree&hb=87345383efae7d7b30c03ea64b > c03f0db37d4d2b Well, you should really have mentioned we had to look at another branch than master, master is the branch we usually look at when reviews are asked. How different is that devel branch from master? Cheers, Albert > > Bruno.
Re: GCompris in kdereview
Le 30/03/2015 00:37, Albert Astals Cid a écrit : > El Dimecres, 25 de març de 2015, a les 23:03:21, Holger Kaelberer va escriure: >> Hi, >> >> let me update some of the points below: >> >> 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. > There's still no .desktop file, as said, i'd really appreciate one. Hi, It there but in the devel branch: http://quickgit.kde.org/?p=gcompris.git&a=tree&hb=87345383efae7d7b30c03ea64bc03f0db37d4d2b Bruno.
Re: GCompris in kdereview
El Dimecres, 25 de març de 2015, a les 23:03:21, Holger Kaelberer va escriure: > Hi, > > let me update some of the points below: > > 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. There's still no .desktop file, as said, i'd really appreciate one. Cheers, Albert > > > Regards, >Holger > > [1] https://techbase.kde.org/Development/Tutorials/API_Documentation > [2] https://www.math.uni-bielefeld.de/~hkaelber/gcompris/apidocs/html/
Re: GCompris in kdereview
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 rega
Re: GCompris in kdereview
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 >> >> >> - 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 >> >> >> - 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. >> >> - 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.
Re: GCompris in kdereview
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 > > > - 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 > > > - 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. > > - 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 Cheers, Albert > > Bruno.
Re: GCompris in kdereview
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 - 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 - 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. - 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. Bruno.
Re: GCompris in kdereview
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. As a side note, you don't ship a .desktop file, which basically makes your app invisible to desktop menus/launchers. Cheers, Albert > > Regards, > > Bruno.a
GCompris in kdereview
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. Regards, Bruno.
