gtk+ apps do not respond to redraw events

[odlg]

After upgrading gtk+-fastscaling 2.10.14-r2 to gtk+ 2.12.11-r3 from ​http://downloads.openmoko.org/repository/testing/armv4t tangoGPS and other gtk applications are no longer useable. It seems that they do not respond to redraw events. Nothing happens when tapping on tabs in the bottom of the screen. When showing the illume window list, and closing it again, the screen is not updated below, except for speed indicator updates and the blue position cursor updates.

[Ebbe]

An ugly way to fix this, is to "minimize" the program by going to home, and then switch back to the gtk-program. Then the program "knows" to redraw the screen.

Navit and openmoko-terminal2 is also affected by this bug.

[Thor]

what ever happened to this bug? It's really a showstopper as it affects one of the best parts of the whole system, GPS, on the one app that worked best with it: tangoGPS.

Can anyone give us some hints about this?

[Weiss]

I've been doing a bit of research into this because it affects me as well. I tried installing a GTK 2.10.14 package onto my Freerunner and the problems went away. I traced through the 2.11 development series between GTK 2.10 and 2.12 (having created a BB recipe): It looked like the problem started between the final development release (2.11.6) and the first stable release (2.12.0). Alternatively, it could be caused by one of the patches from OpenEmbedded? (which are different for 2.12 than for 2.10).

However, TangoGPS works fine on my Ubuntu laptop, GTK 2.12.9.

Has anyone noticed similar things happening with any other GTK programs?

[thomasb]

I can add the observation that GTK+ 2.14.2 seems to work, too (I simply tried the newest version with a BB recipe already available). That version jump is a bit invasive, though, because several dependencies have to be upgraded, too. If there's interest anyway, I can provide a patch against the OM git tree that upgrades the preferred versions in the distro config.

[Weiss]

I think a simple version bump as you suggest would make sense. From the Git history it looks like GTK was only upgraded as a routine jump up to the latest version, so another jump would hardly be a problem. Particularly considering how difficult this problem would be to debug otherwise...

[thomasb]

Well, false alarm I guess: I tried again to reproduce this bug, but now I saw it even with GTK+ 2.14.2. Sometimes the problem occured with the newer gtk version, sometimes it worked with the old one. I haven't found a reliable way to reproduce it yet, but gtk version 2.12.11 vs. 2.14.2 doesn't seem to be a factor.

[john_lee]

it appears in testing repo now...

[TimoJyrinki]

See and evaluate workaround at ​http://lists.openmoko.org/pipermail/devel/2008-November/003215.html
It's far better than the current situation.

[Weiss]

Full details now sent upstream: ​http://bugzilla.gnome.org/show_bug.cgi?id=561591

[haakeyar]

I reproduced this running illume on my desktop (running Ubuntu 8.04).

I compiled the latest enlightenment with raster's get_e.sh[1], and ran it within xephyr. With the regular enlightenment profile, everything worked perfectly. When I changed the profile to illume, the bug appeared. Attached is a screenshot of the bug appearing in gvim running in illume in xephyr.

If I start a gtk+ application with the default enlightenment profile and then change the profile to illume while leaving the application running, the bug does not appear in the running app even though it is running in illume. If I restart the app, the bug appears. (Sorry if I explained it badly, but play with it and you will see what I mean.)

[1] ​http://www.rasterman.com/files/get_e.sh

[haakeyar]

The bug with illume running in xephyr on the desktop.

[john_lee]

Raster created a patch to send extra events to gtk app and should have fixed this issue. Committed to om.dev as c6994deaa633e7bf995b6a30af411348d94e5876