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.
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.
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.
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.
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.
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.
Maybe I'm over-estimating the scope of the change. Is there some silver-bullet approach that will make this trivial?
Cheers, Matthew Brush
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
On 08/29/2011 03:00 AM, Lex Trotman wrote:
On 29 August 2011 17:53, Matthew Brushmbrush@codebrainz.ca wrote:
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 :-)
Heh, ok, it wasn't fun, just trying to avoid the inevitable "it's too early! we only just switched to 2.12!!". I'm writing a plugin for fun, and it's going to require GTK+ 3.
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.
I'm not sure if you've used Glade 3, especially newer versions of it, but it's pretty great IMO. And they wisely got rid of that pesky code generation feature which had the potential to cause some serious grief down the road :)
Out of curiosity, what's the alternative to Glade? If it can only build LCD UIs, what would you use to build a non-LCD UI in GTK+? Surely not hand/hard coded widget building code?
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.
+++++1
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.
Was it going from raw generated C code to LibGlade/GtkBuilder, or was it going from LibGlade to GtkBuilder? I think the former is a more daunting task than the latter, though I could be mistaken.
Cheers, Matthew Brush
[...]
Heh, ok, it wasn't fun, just trying to avoid the inevitable "it's too early! we only just switched to 2.12!!". I'm writing a plugin for fun, and it's going to require GTK+ 3.
Well, I don't think there is anything wrong with looking at GTK-3 but it *is* too early to remove support for GTK-2. I've not looked at what changed for GTK-3, can we support both without much work (after gtkbuilder is incorporated)? Lots of #ifdefs would be bad.
I'm not sure if you've used Glade 3, especially newer versions of it, but it's pretty great IMO. And they wisely got rid of that pesky code generation feature which had the potential to cause some serious grief down the road :)
Only used older glade 3, but a quick look at docs doesn't say a huge amount changed.
Out of curiosity, what's the alternative to Glade? If it can only build LCD UIs, what would you use to build a non-LCD UI in GTK+? Surely not hand/hard coded widget building code?
Sadly yes, you deleted my example from build.c where it is needed.
[...]
Was it going from raw generated C code to LibGlade/GtkBuilder, or was it going from LibGlade to GtkBuilder? I think the former is a more daunting task than the latter, though I could be mistaken.
Same as Geany, glade generated code to builder.
Cheers Lex
On 08/29/2011 05:20 PM, Lex Trotman wrote:
[...]
Well, I don't think there is anything wrong with looking at GTK-3 but it *is* too early to remove support for GTK-2. I've not looked at what changed for GTK-3, can we support both without much work (after gtkbuilder is incorporated)? Lots of #ifdefs would be bad.
Until the snag with the deprecated widgets used in the Glade generated code, the changes were extremely trivial and wouldn't at all break the current GTK+ version support. All of them were documented in the migration guide[1].
A quick list of the changes I had to make: - Update Scintilla since it now supports GTK+ 3. - Replace a few direct member accesses with accessor functions. - Switch from using GtkComboBoxEntry to GtkComboBox. - Replace GtkNotebookPage with gpointer. - Fix use of GDK_<keynamehere> and include of gdkkeysyms.h. - Add some alternate #ifdef'd code for "Height-for-width" layout in the GeanyWrapLabel widget[2]
The last two are the only ones that require some version checking/different code handling. Actually, some of the changes should probably be made even without thinking of GTK+ 3, since they are considered good practice even with GTK+ 2.
[1] http://developer.gnome.org/gtk3/3.0/migrating.html [2] http://developer.gnome.org/gtk3/3.0/ch25s02.html#id1525688
Cheers, Matthew Brush
On 30 August 2011 11:35, Matthew Brush mbrush@codebrainz.ca wrote:
On 08/29/2011 05:20 PM, Lex Trotman wrote:
[...]
Well, I don't think there is anything wrong with looking at GTK-3 but it *is* too early to remove support for GTK-2. I've not looked at what changed for GTK-3, can we support both without much work (after gtkbuilder is incorporated)? Lots of #ifdefs would be bad.
Until the snag with the deprecated widgets used in the Glade generated code, the changes were extremely trivial and wouldn't at all break the current GTK+ version support. All of them were documented in the migration guide[1].
A quick list of the changes I had to make: - Update Scintilla since it now supports GTK+ 3.
Yes, although IIUC GTK-3 support is still experimental
- Replace a few direct member accesses with accessor functions.
So long as the accessors are available in GTK 2.12 otherwise #if hell begins
- Switch from using GtkComboBoxEntry to GtkComboBox.
Well, a ComboBox created with new_with_entry that is.
- Replace GtkNotebookPage with gpointer.
Mostly it seems to be GtkWidget * not gpointer but also some of notebook.c might need a bit more changed since it fakes GtkNotebookPage.
- Fix use of GDK_<keynamehere> and include of gdkkeysyms.h.
Shouldn't be too hard
- Add some alternate #ifdef'd code for "Height-for-width" layout in the GeanyWrapLabel widget[2]
With the new layout capabilities we should first look if we need our own widget any more, less to maintain but more #if.
The last two are the only ones that require some version checking/different code handling. Actually, some of the changes should probably be made even without thinking of GTK+ 3, since they are considered good practice even with GTK+ 2.
True.
Other things to think about:
How to ensure that users download the correct version, since the one executable can't do both, you can only compile and link against one version of GTK. This increases the Geany maintenance workload as there now needs to be two versions supported, tested etc.
How to ensure plugins are linked against the right version, or determine which version they support, that might need two sets of API/ABI say <1000 for GTK2 and >1000 for GTK3.
This looks like a lot more work than the current Geany contributors can handle so I would suggest it will take a while. In the meantime I guess you can either try to make your plugin not require GTK-3 or maintain your own GTK-3 git branch. And of course Geany would also be grateful for patches with those changes that are GTK-2 compatible good practice to start the main project down the road.
Cheers Lex