[Geany-devel] Glade Code Generation and GtkBuilder

[Lex Trotman]

Hey Matthew,


On 29 August 2011 17:53, Matthew Brush <mbrush at codebrainz.ca> wrote:
> Hi,
>
> I was messing around with Geany code to see what it would take to compile it
> against GTK+ 3 (just for fun).  There doesn't seem to be too many changes
> needed, with one *massive* exception: the old code generated by old glade
> versions.

You have some weird concept of fun :-)

>
> At some point in the (possibly distant) future, Geany will (I think) either
> need to switch to using GtkBuilder or just hack-by-hand the `interface.c`
> file (eww), since the old Glade version generates what will be deprecated
> code, and newer Glade versions don't generate code.

As Geany only just went to GTK 2.12 this is the first time that the
problem can be considered.  Already the old glade needs a patch help
to compile (the tool itself) on modern machines.  So it may not be so
far away.

Personally I am not a big fan of Glade, it seems to me to only build
lowest common denominator UIs, but that may be just me.

>
> Has anyone thought about what would be needed to switch from using the
> current generated C UI code to using GtkBuilder?  You can actually open the
> old Glade file in Glade3 and resave it as GtkBuilder XML (with minor
> issues), but it seems like there would need to be a whole lot of work to
> actually use it.

Well IIRC so long as the Glade file was properly laid out most of
interface.c functionality was done by the builder.

>
> At a glance, it seems like most widgets are accessed through
> `ui_lookup_widget()`, so it seems like it would make sense to have that
> function somehow call `gtk_builder_get_object()` to find the widget.  If all
> the Glade widgets are lookup up through this single function, that will
> probably work to our advantage.  I'm not sure how else widgets are accessed,
> or how many are added outside of the `interface.c` file (vte?) or if that
> matters.

Rather a lot are added outside of glade since the Glade built
interface isn't flexible, eg all of build menu and build commands
dialogs since their length can change.  But I don't think thats a
problem, they don't care where the other widgets came from, so long as
the pointer to the widget they attach to is still there then they are
happy.

I'm not sure how much is done by ui_lookup_widget() and how much by
global pointers, but so long as the pointers are still there...

>
> It seems like the callbacks should get connected when
> `gtk_builder_connect_signals()` is called since they seem to stick around
> fine in the GtkBuilder XML file.  I guess this part might not be too much
> problem.
>

Can we fix the names, please please, foo1 foo2 foo3 is really
annoying, its hard to tell which is the one I want, if we need to
break the thing lets put it back together properly.

> I was hoping to start gathering some ideas on the best way to make this
> transition, even though it may be far off in the future.  It seems to me
> like it will require quite extensive changes, potentially producing tons of
> non-obvious bugs popping up in obscure corners of the code.

Sounds like a case for an experimental branch, do you know a good VCS?

>
> Maybe I'm over-estimating the scope of the change.  Is there some
> silver-bullet approach that will make this trivial?

I've only been involved in doing this once, it wasn't too bad, but I
think that UI was a bit better put together than Geany, but Geany is
much smaller than it was.  It is a couple of years ago so the memory
is a bit hazy.

I'm afraid the only bullets involved, silver or otherwise, were the
ones we shot into our own feet :-)

Cheers
Lex