Re: Question about new versions of GTK and Eclipse

[Soeren Sandmann <sandmann daimi au dk>]

Soeren Sandmann <sandmann daimi au dk> writes:

>         - The fact that gtk_container_get_children() now returns a
>           list of GtkToolItem (not to be confused with the Java class
>           ToolItem in the Eclipse sources), not a list of the actual
>           widgets on the toolbar.
> 
>           If this is the case, the problem is harder to fix, because
>           the way the new toolbar works, gtk_container_get_children()
>           really should return GtkToolItems(). The   
> 
>                 if (api_mode == OLD_API)
>                         ;
> 
>           hack that is used elsewhere in the toolbar may work for this
>           problem too, though.

I have looked a bit more on this, and the problem is almost certainly
that the toolbar when used with the old API now returns a list of
GtkToolItems, rather than a list of the widgets that were inserted. I
haven't actually tried to build Eclipse, though, so this is just from
reading Eclipse source, and I may be wrong.

This is how Eclipse works:

There is a class "WidgetTable" that is a map from C pointers,
represented as integers, to Eclipse Java widgets.  This class has a
static method "get" that takes an integer and returns an instance of
the Java class "Widget" that wraps the GTK+ object.

The Eclipse toolbar widget can only contain ToolItems, so to wrap to
old gtk+ widget the getItems() method on ToolBar calls
gtk_container_get_children() and converts each of the pointers to the
corresponding wrappers.

The problem then is that gtk_container_get_children() returns a list
of widgets that the Eclipse system doesn't know about, which causes
the table to convert to null, causing a crash.


It is not obvious to me how to fix this. Possible solutions:

        - Declare Eclipse and similar applications broken. That is,
          say:

                "Depending on gtk_container_list_children() returning
                 the children you inserted was never legal anyway".

          I don't think this is reasonable.


        - Accept and document that gtk+ 2.4 will not be compatble with
          previous versions.

          Also unacceptable in my opinion.

        
        - Change gtk_toolbar_forall() to actually report the
          grandchildren of the toolitems.

          This doesn't work, because lots of places in gtk+ depend on
          containers actually listing all their children. Insane hacks
          are possible, like a global variable that indicates whether
          the function was called from within gtk+, or having "if
          (GTK_IS_TOOLBAR())" all over the place, but neither sound
          appealing to me.


        - Add GtkToolCounter, a new widget with the new toolbar
          functionality, leaving the old GtkToolBar in place. 

          Definitely not ideal, especially at this time.


        - Change GtkToolbar so that when it is used with the old API,
          it doesn't actually have GtkToolItem's in it, but rather the
          real widgets.

          In a sense this is the right solution, but it will require
          major changes and probably involve duplication of much of
          the toolbar code.


Only the last one is a real possibility, as far as I can see. If
anyone has a better solution, I am all ears.


Søren