Trying to open the Journal the first time does not work

[erikos]

Trying to open the Journal the first time does not work, opening the second time does work. Steps to reproduce:

• start Sugar

• click on the Journal icon in the Favorites View

• there is a window switch for a moment but the Journal does not open

• click on the Journal icon in the Favorites View again

---> the Journal does start

• start Sugar

• reveal the Frame and click on the Journal icon

• there is a window switch for a moment but the Journal does not open

• reveal the Frame and click on the Journal icon again

---> the Journal does start

[erikos]

Actually, I just went back to 0.96.2 in the shell and on my F17 systems the issue is the same. /me is digging deeper.

[erikos]

Looking at the 'window-state-event' we get in the JournalActivity we first get a maximize event and then a second one which iconifies again.

1345198322.465396 DEBUG root: window_state_event_cb new_state=<flags GDK_WINDOW_STATE_ICONIFIED | GDK_WINDOW_STATE_MAXIMIZED of type GdkWindowState> changed-mask=<flags GDK_WINDOW_STATE_MAXIMIZED of type GdkWindowState>
1345198322.466413 DEBUG root: window_state_event_cb new_state=<flags GDK_WINDOW_STATE_MAXIMIZED of type GdkWindowState> changed-mask=<flags GDK_WINDOW_STATE_ICONIFIED of type GdkWindowState>
1345198322.468571 DEBUG root: window_state_event_cb visible=True [(<frame object at 0x9ab6f2c>, '/home/erikos/sugar-build/install/lib/python2.7/site-packages/jarabe/journal/journalactivity.py', 327, '__window_state_event_cb', ["            logging.debug('window_state_event_cb visible=%r %s', visible, inspect.stack())\n"], 0), (<frame object at 0x8e23674>, '/home/erikos/sugar-build/install/bin/sugar-session', 277, 'main', ['        gtk.main()\n'], 0), (<frame object at 0x8b277dc>, '/home/erikos/sugar-build/install/bin/sugar-session', 293, '<module>', ['main()\n'], 0)]
1345198322.469575 DEBUG root: visibility_notify_event_cb visible=True
1345198322.470572 DEBUG root: visibility_notify_event_cb visible=True
1345198322.470704 DEBUG root: visibility_notify_event_cb visible=True
1345198322.473049 DEBUG root: window_state_event_cb new_state=<flags GDK_WINDOW_STATE_ICONIFIED | GDK_WINDOW_STATE_MAXIMIZED of type GdkWindowState> changed-mask=<flags GDK_WINDOW_STATE_ICONIFIED of type GdkWindowState>
1345198322.473495 DEBUG root: window_state_event_cb visible=False [(<frame object at 0x9ab6f2c>, '/home/erikos/sugar-build/install/lib/python2.7/site-packages/jarabe/journal/journalactivity.py', 327, '__window_state_event_cb', ["            logging.debug('window_state_event_cb visible=%r %s', visible, inspect.stack())\n"], 0), (<frame object at 0x8e23674>, '/home/erikos/sugar-build/install/bin/sugar-session', 277, 'main', ['        gtk.main()\n'], 0), (<frame object at 0x8b277dc>, '/home/erikos/sugar-build/install/bin/sugar-session', 293, '<module>', ['main()\n'], 0)]
1345198322.473619 DEBUG root: canvas_visibility_notify_event_cb False

Next is to find out where the iconify event is coming from.

[erikos]

Ahh, looks like this has been broken with the update from gtk2, gtk2-2.24.11 to gtk2-2.24.11. Easily reproducible when installing ​http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=80312 on a 12.1.0 build in the XO (or doing an update in F17).

Looking at the commits between 2.24.10 and 2.24.11 this one does smell suspicious: ​http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=3f6592f60fd15fb353fc84600caefba3054dc892

I remove the 'nohippo' flag as the regression has not been introduced by that.

[erikos]

In the current ​OLPC 13.1.0 build you can 'yum downgrade' gtk2 to get this working again.

​http://armpkgs.fedoraproject.org/packages/gtk2/2.24.10/2.fc18/armv7hl/gtk2-2.24.10-2.fc18.armv7hl.rpm

(if gtk2-devel is also installed) ​http://armpkgs.fedoraproject.org/packages/gtk2/2.24.10/2.fc18/armv7hl/gtk2-devel-2.24.10-2.fc18.armv7hl.rpm

[erikos]

Is as well present in the GTK+ 3 shell.

[tonyforster]

Looks like this applies to all Activities, clicking on the icon, either in the home view or in the top of the frame

[erikos]

Replying to erikos:

Ahh, looks like this has been broken with the update from gtk2, gtk2-2.24.11 to gtk2-2.24.11. Easily reproducible when installing ​http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=80312 on a 12.1.0 build in the XO (or doing an update in F17).

Looking at the commits between 2.24.10 and 2.24.11 this one does smell suspicious: ​http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=3f6592f60fd15fb353fc84600caefba3054dc892

In GTK+ master the commit from above landed as well: 1c970036648bffd5d58499bb7c8e2439b84d4397

[dsd]

I suspect that previously we never really iconified the Journal window correctly, but with the new GTK+ code maybe we do so now, which triggers a behaviour change.

Adding

         window.unminimize(Gtk.get_current_event_time())

in CurrentActivityIcon.button_release_event_cb solves this but causes some visual oddness first.

The root of the problem here is that we iconify the Journal when it is launched. I'm wondering if we have any other options here. We don't iconify windows under any other circumstances, as far as I can see.

Another option would be to look at the wnck code and compare how it handles iconify/deiconify.

I still haven't got my head around the event flow in window-state-event so I'm not very confident about the above.

[dsd]

I don't think there are any other options at hand other than starting the Journal in iconified state. X and GDK do have support for mapping windows without displaying them (e.g. gdk_window_show_unraised()) but GTK+ does not support this.

(In fact, maybe we should be iconifying non-active activities in addition to the Journal. This might cause them to be unmapped, saving memory.)

Back to the problem at hand...

[dsd]

Looks like a GTK+ regression, trivial to reproduce outside of Sugar. ​https://mail.gnome.org/archives/gtk-devel-list/2012-September/msg00042.html

[tonyforster]

still present in OS3

[dsd]

its a metacity bug, ​https://bugzilla.gnome.org/show_bug.cgi?id=684741

[dsd]

Fixed in metacity-2.34.13

[greenfeld]

metacity-2.34.13 is in OLPC 13.1.0 os7 and I could not reproduce in the issue mentioned in that build.

[dnarvaez]

Milestone 0.98 deleted