Hey Matthew,
On 29 August 2011 17:53, Matthew Brush mbrush@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