Created attachment 158614 [details] [review]
Major work on the GSEAL compliance.

Here's my kick at this bug, unfortunately, I couldn't get it all done because of some bitwise magic I'm not familiar with and the GtkMenu "active" property I couldn't deal with.

Also, worth mention, I included <stdlib.h> in a file using the standard exit() function, I don't know if this is common practice.

Some questions about GtkAllocation : when should I use a pointer and when shouldn't I ?

Overall, this patch is kinda large and I'm not a Gtk expert, so please double-check it !

Thanks for working on this!
Patch is missing a bump in configure.ac which currently says GTK_REQUIRED_VERSION=2.12.0

We should probably commit this for 2.31 but not 2.30 branch (i still need to look it over)

(In reply to comment #1)
> Some questions about GtkAllocation : when should I use a pointer and when
> shouldn't I ?

Basically it's always

+ GtkAllocation allocation;
+ gtk_widget_get_allocation (widget, &allocation);
- widget->allocation.width;
- widget->allocation.height;
+ allocation.width;
+ allocation.height;

(In reply to comment #3)
> We should probably commit this for 2.31 but not 2.30 branch (i still need to
> look it over)

Definitely 2.31-only stuff. The earlier it's in the better so we can find potential accessors in gtk+ that are still missing.

I committed the patch in comment #2.  I did not update configure.ac to specify
a newer version of GTK.  What version should be specified there?  Let me know and
I will update this also.

GTK_REQUIRED_VERSION=2.12.0

Is this work done, or is more work needed?

Brian: "Newest" symbol I found in your commit diff is gtk_widget_get_realized() which was introduced in GTK+ 2.19.7. So probably bump to 2.20 and you're fine.


This report can be closed once entire gdm compiles with -DGSEAL_ENABLE. (When it does compiling can only fail again if somebody writes old-style code in gdm but it cannot fail again because for example the gtk+ team changes something.)
Hence setting -DGSEAL_ENABLE as a default flag somewhere in configure.ac is encouraged.

I have just fixed two trivial issues in http://git.gnome.org/browse/gdm/commit/?id=cb80e59f93b6069dd3fe46f8ed22af853901cfda so the only issues that are still left to fix are:

gui/user-switch-applet/applet.c: In function ‘applet_key_press_event_cb’:
applet.c:374: error: ‘GtkMenuShell’ has no member named ‘active’
applet.c:376: error: ‘GtkMenuShell’ has no member named ‘have_grab’
applet.c:377: error: ‘GtkMenuShell’ has no member named ‘active’
gui/user-switch-applet/applet.c: In function ‘fill_applet’:
applet.c:1511: error: ‘GtkObject’ has no member named ‘flags’
applet.c:1511: error: ‘GtkObject’ has no member named ‘flags’

Thanks.  I updated configure.ac so that the GTK required version is 2.20.0 and the line now reads as follows:

GTK_REQUIRED_VERSION=2.20.0

*ping*
Can the few remaining issues please be fixed soon (next two weeks, before 2.31.4)?

I've fixed the flags part in master.  However, I'm not sure what to do about the following code:
/*
 * gnome-panel/applets/wncklet/window-menu.c:window_menu_key_press_event()
 */
                /*
                 * We need to call _gtk_menu_shell_activate() here as is done in
                 * window_key_press_handler in gtkmenubar.c which pops up menu
                 * when F10 is pressed.
                 *
                 * As that function is private its code is replicated here.
                 */
                if (!menu_shell->active) {
                        gtk_grab_add (GTK_WIDGET (menu_shell));
                        menu_shell->have_grab = TRUE;
                        menu_shell->active = TRUE;
                }

And not really sure what it is doing either.

A bit of history:

WnckSelector is a GtkMenuBar with a single item.  That item has an image (the current window's icon), and a submenu which actually *is* the menu of all windows.

GtkMenuBar of course descends from GtkMenuShell.

GtkMenuShell is this old lumbering beast.  _gtk_menu_shell_activate() is private just for historical reasons; there's no good reason to keep it from being public.  It is just used to pass around grabs between nested submenus (see how it is called in gtkmenuitem.c).

The code in the panel (and now gdm) is already a bit obsolete; GTK+ has this pattern in gtkmenubar.c:window_key_press_handler():

  _gtk_menu_shell_set_keyboard_mode (menu_shell, TRUE);
  _gtk_menu_shell_activate (menu_shell);
  gtk_menu_shell_select_first (menu_shell, FALSE);

We could very well add a gtk_menu_shell_fire_and_forget_from_the_keyboard() that does all that.  Patches welcome ;)

master compiles fine against current gtk3

FWIW, for gnome-panel (fallback) I was expecting that once gdm
had a solution for this hack, we could apply it to gnome-panel,
too.  In the meantime, we were working in fixing other 
issues.

However, we can not delete the menu from the panel.
Any suggestion? (rather than using Xlib directly).