[gcompris-devel] sorting boards

[Bruno Coudoin]

le mar 16-10-2001 at 21:01 pgeorges a écrit :
> Bruno Coudoin a écrit :
> 
> > > 2. I tried to add some special stuff to congratulate the child (or
> > > showing he's wrong). But this may need more drawing skills than I have.
> > > The best would be to use sprites, but I only know QT for this purpose.
> > > When I look at my cpumeter when paratrooper is in use, I am afraid of
> > > current performance for image drawings.
> > I is true that the gnome canvas is not the best tool to display
> > intensive moving icons. To this regards, I should have use SDL in the
> > first place.
> > So if I understand your smiley will be an animation?
> 
> No, as I don't know gnome API, it is still ugly images (I am not a
> graphist).
> For SDL, I don't see the point for using it. Qt (not KDE libs) would
> have been a sufficent choice (it manages quite well sprites and sound
> for example).
Well, I don't know, but SDL seems more gaming intensive oriented, there
is many developpers in this area using it. Just a feeling.

> 
> > > PS : I just discovered sodipodi, which is a great vector drawing app,
> > > giving sometimes better results than gimp.
> > Yes, I now it. I have been in touch with the author regarding SVG usage
> > in the gnome canvas. Since I use xml, for the shape board it would be
> > good is a teacher could create a board using sodipodi.
> > For now, the only way to use svg images is to use the librsvg from gnome
> > that can render an svg image to a pixmap that then can be loaded in a
> > canvas object.
> 
> For me, there is no interest in using SVG for display : it is more CPU
> intensive than bitmaps and certainly harder to incorporate into
> gcompris.
> So I make a SVG drawing and then export it to PNG.
Yes, it has at list one advantage in being able to have a unique drawing
source independently of the target size. PNG are good to reduce but
loose quality when enlarged.
It is complex to managed at the same time an efficient icon size and
quality. Some time you will find in the gcompris image pool some that
are too small for you, and you will have to create a bigger one.
Anyway, it is ok like we are on this topic today in gcompris. One
problem at a time ;)

> 
> > I am still looking at an easy way to implement an authoring tool on top
> > of gcompris to let teachers create their boards.
> 
> Maybe the first step is to list all different kind of boards (with or
> without images, with choice lists, etc ...). But it will always limit
> freedom of development, unless it is as complete as tools like former
> "klik'n play".

My idea is to extend each board to let it edit itself.
For example if you take the shape board, it could enter an edit mode,
let you import pixmaps, select target point and backgrounds and then
create and save the .xml board data file. That's it.
If it is not relevent for a board to be edited then it will not provide
this entry point.

Comparing to klik'n play, I think this approach is more relevent because
it really split the developpers (create .c boards) and the educators
(create .xml board data) words.