I've noticed unwanted window resizing behaviour with metacity (gnome) too, but
no maximizing thats really a kwm bug.

Let me explain the problem:
gcompris uses Xrandr to change to reolution for the fullscreen "window" its 
creates. By default it changes the resolution to 800x600 under metacity this
causes all my > 800x600 windows to become 800x600 except for maximized ones
whicg just stay maximized. I've tried working around this by changing the
resolution gcompris switches to to 1024x768 but strange enough that doesn't help
it as as if gcompris doesn't honor its own resolution setting.

Appearantly KDE (kwm) decides to maximize all smaller windows, does this happen
with real small windows too?

Anyways I'll look into this but I don't know an easy fix. I'm happy to see
others using gcompris though, do you like it (except for this bug)?

Okay, I have two xterms and one resizes horizontally about 2.5x its normal width
while the other did not resize at all.  The konsole in which I ran gcompris in
maximized vertically.  Firefox and kmail both maximize horizontally and
vertically as well as a konsole that runs irssi.  gkrellm relocates itself to
the upper right corner of the screen.  beep-media-player remains unaffected.

Also, the following gets output to the konsole:
$ gcompris

** (gcompris:3623): WARNING **: config_file /home/chris/.gcompris/gcompris.conf
** Message: gcompris_set_locale ''


** (gcompris:3623): WARNING **: Requested locale '' got 'en_US.UTF-8'
Opened audio at 44100 Hz 16 bit stereo, 2048 bytes audio buffer

(gcompris:3623): Assetml-WARNING **: assetml_get_asset file=welcome.ogg: no match


(gcompris:3623): Assetml-WARNING **: assetml_get_asset file=fantastic.ogg: no match

2006-05-06 11:52:39;rivendell;chris;gcompris;memory_sound;2;0;PASSED;43;;

(gcompris:3623): Assetml-WARNING **: assetml_get_asset file=super.ogg: no match

2006-05-06 11:53:22;rivendell;chris;gcompris;memory_sound;3;0;PASSED;33;;

(gcompris:3623): Assetml-WARNING **: assetml_get_asset file=level.ogg: no match


(gcompris:3623): Assetml-WARNING **: assetml_get_asset file=U0034.ogg: no match


(gcompris:3623): Assetml-WARNING **: assetml_get_asset file=level.ogg: no match


(gcompris:3623): Assetml-WARNING **: assetml_get_asset file=U0035.ogg: no match

sdlplayer_bg
/usr/share/gcompris/boards/music/background/Mozart__WA_-_String_Quartet_No.2_in_D_Mvmt_3.ogg

(gcompris:3623): Assetml-WARNING **: assetml_get_asset file=quit.ogg: no match


I've only played the memory match game so far, and it's pretty cool.

Okay,

I've rewritten the fullscreen code to use good old XF86VidMode instead of
Xrandr, that should fix all issues. Please give gcompris-7.4-7 from devel a spin
once released, or build it from CVS yourself.

To get rid of the assetml warnings and make gcompris more fun install
gcompris-sound-en (or -ge -sv -nl, -whatever your native language is)

Wow that was fast!  Nice work.  I did not see any gcompris-sound packages in the
repository, are these built for FC-5?

Thanks!

What are you using to install? the gcompris-sound-xx packages are not listed in
Pirut (should I add them? There are a lot of them) They are subpackages of
gcompris, so if gcompris is available so should the -sound-xx packages be.

p.s.

Let me know how the new version works for you.

I checked out the new gcompris from CVS and did a build and it works great.  The
only problem is that the max resolution is 1024x768 and I'm running 1600x1200. 
When I launch tuxpaint from gcompris it goes full screen properly.

The gcompris-sound-* packages were not showing up in the repositories yesterday
when I ran the command "yum list grompris\*" from the shell prompt.  However,
they are there today, I can't explain why.  I've heard the mirrors have been
really whacky lately, perhaps this was the cause.

I also noticed that games like Shippy are stored in the Games->Arcade submenu in
KDE.  Would it be possible to store Gcompris in the Games->Kidsgames submenu for
KDE?

(In reply to comment #7)
> I checked out the new gcompris from CVS and did a build and it works great.  The
> only problem is that the max resolution is 1024x768 and I'm running 1600x1200. 
> When I launch tuxpaint from gcompris it goes full screen properly.
> 

Actually gcompris will always run in 800x600, the resolution config setting is a
dummy iow it doesn't do something. I wanted to nag upstream about removing it,
but sofar I haven't made the time to send a mail with the removal request to
them, I'll do so shortly.

However even with the resolution being hardcoded to 800x600 it should still work
fine, it should change the resolution to 800x600 while fullscreen, thus
completly filling the screen and then switch back to your original resolution
when exiting fullscreen.

Which release did you build -7 or -8? -7 misses a few BuildRequires which may
not be on your system, in that case XF86VidMode support won't be compiled in.

Okay, I tried the -8 version, and this one works properly.  My only other
comment would be to put the menu items under Games->Kidsgames in KDE menu, I
think this would be better than just Games or an Education menu item.

One other thing I've noticed is that now when you move the mouse to the bottom
or right edge of the screen, the gcompris window will scroll off the screen and
show the desktop.

(In reply to comment #10)
> Okay, I tried the -8 version, and this one works properly.  My only other
> comment would be to put the menu items under Games->Kidsgames in KDE menu, I
> think this would be better than just Games or an Education menu item.
See my reply to your related mail on the fedora-games-list. I'm leaving things
as they are untill we have some kinda resolution for this.

(In reply to comment #11)
> One other thing I've noticed is that now when you move the mouse to the bottom
> or right edge of the screen, the gcompris window will scroll off the screen and
> show the desktop.

Arg,

That shouldn't happen, that means that the gdk_grab_pointer which should confine
the mouse to the gcompris window fails. GRRRR. Stupid KDE probably has the mouse
grabbed for no good reason when gcompris tries to grab it.

It might just be an unlucky race, have you tried this multiple times and does it
happen each time?

I've tried it here at work on a completly different machine and setup then at
home and it works fine. I'll see if I can reproduce your problem with KDE (GRRR
I get to many KDE related bugs).

I've managed to reproduce this but normally it doesn't happen, not even with
KDE. Does it happen always for you?

I can only reproduce it by starting gcompris and then drag a selection rectangle
over the desktop background before the gcompris window shows keeping my left
mouse button clicked until after gcompris is started.

I see 3 possible fixes:
1) Don't fix it
2) Keep the gdk_grab_pounter in a while loop with 1 seconds sleeps untill it 
   succeeds, give up after 15 tries (15 seconds) and then just run windowed
3) Try the grab once and if it fail just run windowed.

Which do you think is best?

Hmm, okay I tried a few more times and now I cannot reproduce it.  There must
have been something I ran yesterday in gcompris which caused it to take place,
so for now I would say 1) is best option.

However, during my tests today, I've noticed that when I launch tuxpaint the
screen just goes black.  I have to ctrl-alt-F1 and kill the gcompris process,
then tuxpaint will show up.  This is strange because launching tuxpaint from
gcompris worked before.  I will do some more tests this evening and let you know
if I find out more information.  Can you reproduce the tuxpaint problem?

Okay I found the culprit.  Just run the Tower of Hanoi game and then mouse
sliding off edge of screen bug will show up.

Ah, so the Tower of Hanoi game permanently grabs the mouse and its not
fullscreen? That's ugly!

What do I need todo to start the tower of hanoi games (its not in ym games menu,
what packages do I need to install and / or how is it named in the menu?).

I can reproduce the tuxpaint problem, tuxpaint tries to grab the mouse too, and
it has solved the grab failing by retrying untill the grab succeeds which it
never will because gcompris has it grabbed, this is fixable.

What happens when you start tuxpaint directly with the Towers of Hanoi running?
I would expect tuxpaint to hang in this scenario too.

To launch the tower of hanoi program, you run gcompris, then click on the
rubicks cube icon, then click on the hanoi icon (didnt try the simplified
version).  I'm not sure how to run tuxpaint and hanoi at the same time from
gcompris as you have to quit hanoi to get back to the gcompris menu to launch
tuxpaint.  Hope this helps.

Ah,

Now I get it, I didn't understand when reading your previous comment that with
tower of hanoi you meant the tower of hanoi build into gcompris, I thought you
were running a seperate towerofhanoi game and then without closing that started
gcompris.

I've been able to reproduce both the tower of hanoi problem (which was present
in all activities that use drag and drop) and the tuxpaint problem. And after
some struggling I've managed to fix both. 7.4-9 should hit the mirrors within a
day or 2 and has both issues fixed.

p.s.

The menu stuff needs some more discussion IMHO, maybe you can bring this up on
f-e-l it doesn't seem to get much discussed on the games list probably because
nobody in the games list knows if a nested menu is possible and if it is how.

I tried the -10 release and the tower of hanoi problem is still showing up for
me.  It does not happen on any drag and drop game.  For example, the "simplified
tower of hanoi" works but "tower of hanoi" does not work.

tuxpaint launches fine now.

Weird, both tower of hanoi versions work fine for me. Both on x86_64 and i386.
I'm using rawhide, maybe there is something in FC-5 which causes this?

I've done a little more testing, and you are right, it is present in all drag
and drop motions.  I've noticed that it turns off and on also.  For example once
the bug is present, it has a chance of fixing itself upon the next drag and drop
motion.  I've also noticed that while dragging you can sometimes drag off the
edge of the screen.

Can you try dragging items off the edge of the screen for a while?  I thought
before that the simplified tower of hanoi did not show this bug, but after
several drag and drop operations it showed up.

Same for the chess game.  I test the edge case on every drag and drop move. 
Sometimes you can drag off screen and sometimes you can't.

I'm sorry but I still can't reproduce this. You could take a stab at fixing it
yourself, the relevant piece of code is quite (spelling? educate me please)
small gcompris-7.4/src/gcompris/gcompris.c : 828:
/* Use these instead of the gnome_canvas ones for proper fullscreen mousegrab
   handling. */
int gcompris_canvas_item_grab (GnomeCanvasItem *item, unsigned int event_mask,
                            GdkCursor *cursor, guint32 etime)
{
  int retval;
  
  retval = gnome_canvas_item_grab(item, event_mask, cursor, etime);
  if (retval != GDK_GRAB_SUCCESS)
    return retval;
  
#ifdef XF86_VIDMODE
  /* When fullscreen override mouse grab with our own which
     confines the cursor to our fullscreen window */
  if (properties->fullscreen && !properties->noxf86vm)
    if (gdk_pointer_grab(item->canvas->layout.bin_window, FALSE, event_mask,
          window->window, cursor, etime+1) != GDK_GRAB_SUCCESS) 
      g_warning("Pointer grab failed");
#endif
  
  return retval;
}

void gcompris_canvas_item_ungrab (GnomeCanvasItem *item, guint32 etime)
{
  gnome_canvas_item_ungrab(item, etime);
#ifdef XF86_VIDMODE
  /* When fullscreen restore the normal mouse grab which avoids
     scrolling the virtual desktop */
  if (properties->fullscreen && !properties->noxf86vm)
    if (gdk_pointer_grab(window->window, TRUE, 0, window->window, NULL,
          etime+1) != GDK_GRAB_SUCCESS)
      g_warning("Pointer grab failed");
#endif
}


The problem is that the gnome_canvas_item_(un)grab methods do / release a
mousegrab of their own in the grab case the problem is that the gnome-canvas
grab is not confined to any window allowing the dragging of the screen, in the
ungrab case the problem is that it actually ungrabs :)

In the grab case the fix is to redo the gnome-canvas grab exactly as done by
gnome-canvas (otherwise the drag-drop breaks) but then with a proper confine-to
paramter past. In the ungrab case the fix is to immediatly after the ungrab
restore our own grab again.

Well I guess it's fixed in FC6 because I can reproduce it quite easily with FC5
in gnome and kde.  At least 1 out of 10 drag/drop operations will produce the
bug.  I guess I will test again when FC6 is released.