[Sugar-devel] GCompris packaging

[Aleksey Lim]

On Thu, Jun 10, 2010 at 11:56:32PM +0000, Aleksey Lim wrote:
> On Fri, Jun 11, 2010 at 01:18:34AM +0200, Bastien wrote:
> > Hi Bernie and all,
> > 
> > Adding Bruno to the conversation -- he's the main developer of Gcompris
> > (outside Sugar) and I'm not 100% sure he's on this list.
> 
> He is... but at this moment he could be trying to figure out how to
> use gimp to change the walls texture IRL to refresh his apartment :)
> 
> > He might have
> > ideas about this.
> > 
> > Best,
> > 
> > Bernie Innocenti <bernie at codewiz.org> writes:
> > 
> > > (copying the tecnologia@ and sugar-devel@ lists for their information)
> > >
> > > Pacita, meet Aleksey, a very active contributor of Sugar, maintainer of
> > > the Sugar Labs activity library (ASLO) and packager of GCompris.
> > >
> > > Aleksey, meet Pacita, the lead of the education team of Paraguay Educa,
> > > who has a very strong background on pedagogy and teaching materials.
> > >
> > >
> > > The old monolithic bundle of GCompris was 70MB so big that it was
> > > causing problems at all levels with the limited disk space of the XO-1.
> > >
> > > The new strategy of pulverizing GCompris into a hundred tiny bundles
> > > made it unmanageable with the current shell (updater, launcher,
> > > switcher, etc).
> > >
> > > After separate discussions with Pacita and Aleksey, we all seem to agree
> > > that GCompris needs to be repackaged differently. From a technical
> > > standpoint, breaking GCompris into 4-5 activities would be ideal.
> > >
> > > However, it's not clear yet how the break should be done to make it more
> > > useful in the classroom: by subject? by age group? by curriculum?
> > > Educators can offer important input on this.
> 
> Pacita, what about this workflow:
> 
> * teacher creates new GCompris Administration[1] activity object, to
> 
>   * add change content of Classes, Groups and Profiles;
>     different Administration instances will share this data to not
>     recreate it every time
>   * set activities list for this particular GCompris Administration
>     object
> 
> * teacher saves and shares GCompris Administration object
> 
> * students join this object and follow regular GC workflow
> 
> * teacher in runtime mode, can observe results in Reports tab in
>   GCompris Administration

There is also another point to consider - Journal objects. I've added
Journal integration (store documents created within GC activities in
Journal) to Wordprocessor, Anim and Draw activities (I guess there are
no other activities that create documents). In these activities I hide
regular load/save buttons (that open regular fs tree dialog), so user
all time is working with the same document (which is common for other
sugar activities).

But since there is a plan to have single GC, I have to store documents
from GC activities in the same Journal entry (which is unusual for sugar
but since it is not about adding new workflow but reusing existed GC's,
I guess it is ok).

So, the question, are you considering workflows with creating documents
within GC activities and what is preferable way (within sugar)? In my
mind it could be something like: any joined user (including teacher),
for activities that create documents, can open regular sugar object
chooser (instead of fs tree dialog) to import files from local Journal,
also import document that are created by joined users within this GC
session (could be useful e.g. to see what student did).

> [1] http://gcompris.net/wiki/index.php?title=Manual#Administering_GCompris

-- 
Aleksey