[gcompris-devel] Re: Wishes for 2003

[Bruno Coudoin]

Le mar 07/01/2003 à 20:57, Herman Bruyninckx a écrit :
> On 7 Jan 2003, Bruno Coudoin wrote:
> 
> [...]
> > > To improve:
> > > - modularity of code: separate logic of a game from the graphical widget
> > >   set. (In order to improve portability and cleanliness of code.)
> > That's already the case but some activity do not have associated data
> > because sometimes it doesn't make sense. For example the time reading
> > (clock) is designed to do time reading and only that. I don't see what
> > it could to more.
> I can :-) For example, I would think it's useful to use the same board
> for clock arithmetic: ask the kid to add twenty minutes to the current
> time, etc.
You are right, it is a good example.
To implement this in gcompris, you have several choices:
- copy the old board with the clock to create the new one (WORST)
- add the clock arithmetic code in the current clock and use an xml
option from the xml board description to tell wich activity is requested
(see the option mode="*" in albebra_by.xml.in for example)
- Create a widget out of the clock itself in a seperate .c file and use
it from the old and new activity.

Of course, the later more state of 'the art designed' and I encourage
it.
Now, in practice, it is hard to imagine first what will be usefull to
gadgetize this way. Forcing this aproach would make the entry barrier in
gcompris harder (we need more activity coders in the first place).

Of course if we achieve a good level of gadgetisation, it should help
people create new board faster.

> 
> [...]
> > > - documentation for users:
> > >   - on line: help with a board.
> > We have a great infrastructure in gcompris to do this with the xml
> > boards definitions.
> The infrastructure is fine indeed, but the contents is not comparable to
> commercial applications :-) I know that this is a hard comparison to
> make, but consider it as a complement on the level that GCompris has
> reached already :-) And of course, I should volunteer to help you
> out....
It's noted ;)
> 
> > Now and this is new, still from the xml, I create a great open office
> > documentation ready to be printed and distributed to teachers.
> > Today only in french:
> > http://www.ofset.org/gcompris/gcompris-maitre-fr.sxg
> > http://www.ofset.org/gcompris/gcompris-manuel.sxw
> I see no point in given documentation in OpenOffice format! It's not
> because it is an open format that it is a useful format. Documentation
> to users should be in HTML and/or PDF, not in a text processor format.

Good point,
Today we have the 'info' format (try info gcompris), the html format,
the web site and I can just print as PDF the latest document.

> 
> > So what we miss is one person willing to help us write the documentation
> > when it is missing.
> Indeed....
> 
> > Also at ofset, we want to use 'education' terms in order to close the
> > gap beetween software and the teachers.
> > This requires to have 'real teacher' helping us on that.
> Indeed... Therefore I expect a lot form the inclusion of GCompris in
> such CD compilations such as FreeDUC and Knoppix...

So do we ;)

> 
> > > - develop/adapt a "motion description" API, in order to build more
> > >   dynamic boards.
> > No sure what you mean here.
> > gcompris is based on the gnome canvas that makes this kind of thinks
> > easy but not 'smooth'.
> Indeed, the SDL (Simple Direct Media Layer) is a platform-independent
> API to program animation. I think it is worthwhile for this portability
> alone, but also for its more advanced animation features than Gnome.
> There are some quick tutorials at
>  <http://www.libsdl.org/tutorials.php>
> Of course, Gnome has also become somewhat portable.
> 
Yes it may be a very good advantage to be able to run on Windows using
SDL. But I wonder if at the migration speed we have, windows will still
exist by the time we complete the port ;)))

The real disavantage of SDL is that it is a lower level of programming.
In the canvas, I can just create a group of 3 objects, in 3 lines of
code and then moving the root object moves the other. I can tell an
object to go forward/backward and all this makes the development faster
and let us create more high level activities.

> > > - stability: all versions till now do crash from time to time. And they
> > >   take my Gnome environment with them...
> > Oops.
> > I also saw gcompris crashed but it has never bring gnome in my case.
> I've been looking several times for the reason, but I can't find it :-(
> 
> > I agree to focus on stability but I need help from others.
> > Send me bug reports, stack traces and so on to help me track the bugs.
> I will, as soon as I can reproduce the bug in a repeatable way. It is of
> course very well possible that the real cause lies somewhere else than
> in GCompris.

I HOPE SO ;)

> > > More activity:
> > > - more contents (jig saws, math quizes, ...)
> > Of course, I spend most of my time doing this and I can't do more so:
> > any coders out there please help us ;)
> Yes, please do! (I'm talking to myself here :-)
> 
> > For info, since the creation of gcompris, we have now more than 40
> > different activities. This is a 2.5 year old project.
> > Gcompris creates new activity at a rate of let's say ONE/MONTH.
> > I am prety happy with this ;)
> Of course! Congratulations by the way. But you asked for suggestions,
> didn't you :-)

Yes sorry, as the creator of my baby gcompris, I have a tendency to
overly protect it. Forget that.


>  Maybe some focued advocacy actions towards a students
> public could be successful, especially if there is some price involved.
> I am willing to donate for example 100EUR for this purpose, and if other
> people join in a cash price of let's say 1000EUR in combination with
> lots of noise on the Linux channels could get the necessary interest :-)
> 

That's a great idea. Do you have an idea on how we could promote and
manage this ?
BTW, I personaly have no money to put in.

On this topic, I registered gcompris in a contest done on
http://www.happypenguin.org/

No money to win :(

> >
> > > - cooperation with other projects, in order to share code and
> > >   experiences. (Tuxpaint comes to my mind as an obvious candidate,
> > >   because both projects target the same user group.)
> > Tuxpaint is a great project. I got many good review of it. Now I don't
> > see in what we could cooperate.
> Seems obvious to me: in the same way you integrated the maze board form
> a stand-alone project, you could integrate tux-paint as the
> replacement of/addition to the simple drawing board in GCompris.
> 
Yes but we have a toolkit issue. Tuxpaint is an SDL application.

Also, tuxpaint by itself is wellknown, well maintained and in this case,
it maybe better to keep its author improve its project.


> > BTW, some attend to cooperate with the KDE EDU team failed. They are KDE
> > oriented and are not interrested to improve a gnome application.
> 
> That's one of the reasons why a Gnome/KDE independent library such as
> SDL makes sense: the basic contents of the project are independent of
> the "big two", and all you need is some GNome and KDE wrappers.

Sure.
I am really open on that, if somebody can make a kind of proof of
concept showing us how to port just one board to SDL, we will then
evaluate the effort to complete the port and do it if it is worth the
pain.
But for now, I personnaly prefer to stick to create more content in the
existing framework.

> 
> Herman