Hi,
I just wanted to let everyone who I haven't bothered on IRC know that I'm working on converting the old Geany Glade 2 generated user-interface code to Glade 3 using GtkBuilder.
I'd like to get this committed to Geany shortly after the 0.21 release if possible. It requires a minimum GTK+ version of 2.16 due to the use of GtkBuilder, which may or may not be a problem.
I figure if there's any chance of Geany upgrading to a minimum of GTK+ 2.16 then it would be beneficial to do so early after the next release. If there's no chance of updating to GTK+ 2.16 after the next release, then ignore the rest of this email.
The changes add two API functions to Geany; ui_lookup_object() and ui_hookup_object() which behave similarly to their widget counterparts. The old ui_lookup_widget() and ui_hookup_widget() are deprecated in favour of the new functions, but they still work as before. The first parameter to these functions, the parent widget, is no longer used. The new functions are added to the plugin API.
I've also taken the liberty of porting the Terminal/VTE preferences UI to the new Glade 3 format rather than being hard-coded. IIUC if the VTE/terminal is not enabled for whatever reason, the "Terminal" tab in the preferences dialog just won't be shown.
The new code adds a GHashTable which is used to "register" GObjects, either from the GtkBuilder file (data/geany.glade) or added elsewhere with the ui_hookup_object() function. Each GObject registered is referenced when hooked-up and de-referenced when the new ui_finalize_builder() function is called.
I honestly have no idea what the implications of this change are in regards to i8n translations, but IIUC there is a facility for this in the GtkBuilder file.
One bug I've experienced, which may be unrelated to my changes, is that the main VBox splitter (between the sidebar/documents and the message window) position is not remembered. The position is stored in the keyfile but it's not reloaded the next time Geany is run. I've had a brief glance at the relevant code and I couldn't spot any obvious problems.
If anyone feels like giving me a code review, feedback or testing the changes, I have a branch on my geany repository on GitHub. My working copy, which is rebased on Geany's Git repository every now and then can be found at:
https://github.com/codebrainz/geany/tree/gtkbuilder
Cheers, Matthew Brush
Hi Matthew,
On Sun, Sep 25, 2011 at 10:53, Matthew Brush mbrush@codebrainz.ca wrote:
Hi,
I just wanted to let everyone who I haven't bothered on IRC know that I'm working on converting the old Geany Glade 2 generated user-interface code to Glade 3 using GtkBuilder.
I'm really happy about this change. First we get rid of the horrible old glade editor and second it's the most important step towards making Geany compile under GTK 3. Thanks for your work!
I'd like to get this committed to Geany shortly after the 0.21 release if possible. It requires a minimum GTK+ version of 2.16 due to the use of GtkBuilder, which may or may not be a problem.
I figure if there's any chance of Geany upgrading to a minimum of GTK+ 2.16 then it would be beneficial to do so early after the next release. If there's no chance of updating to GTK+ 2.16 after the next release, then ignore the rest of this email.
The changes add two API functions to Geany; ui_lookup_object() and ui_hookup_object() which behave similarly to their widget counterparts. The old ui_lookup_widget() and ui_hookup_widget() are deprecated in favour of the new functions, but they still work as before. The first parameter to these functions, the parent widget, is no longer used. The new functions are added to the plugin API.
I've also taken the liberty of porting the Terminal/VTE preferences UI to the new Glade 3 format rather than being hard-coded. IIUC if the VTE/terminal is not enabled for whatever reason, the "Terminal" tab in the preferences dialog just won't be shown.
The new code adds a GHashTable which is used to "register" GObjects, either from the GtkBuilder file (data/geany.glade) or added elsewhere with the ui_hookup_object() function. Each GObject registered is referenced when hooked-up and de-referenced when the new ui_finalize_builder() function is called.
I honestly have no idea what the implications of this change are in regards to i8n translations, but IIUC there is a facility for this in the GtkBuilder file.
One bug I've experienced, which may be unrelated to my changes, is that the main VBox splitter (between the sidebar/documents and the message window) position is not remembered. The position is stored in the keyfile but it's not reloaded the next time Geany is run. I've had a brief glance at the relevant code and I couldn't spot any obvious problems.
If anyone feels like giving me a code review, feedback or testing the changes, I have a branch on my geany repository on GitHub. My working copy, which is rebased on Geany's Git repository every now and then can be found at:
I gave it a quick try and in general it appears to work really great (i.e. I don't see any difference between this and the old version).
The only glitch I have noticed is that under Document->Indent Type, Document->Indent Width and Document->Set Line Endings all the items are selected with the radio selection circle. The fix is to disable "Active" for these items in the glade editor (not attaching patch because for some reason Glade changes also other elements in the XML file when I save it). Not sure if they were active before or there is some bug in the conversion from the old format.
Cheers,
Jiri
On 09/25/2011 06:41 AM, Jiří Techet wrote:
Hi Matthew,
On Sun, Sep 25, 2011 at 10:53, Matthew Brushmbrush@codebrainz.ca wrote:
Hi,
If anyone feels like giving me a code review, feedback or testing the changes, I have a branch on my geany repository on GitHub. My working copy, which is rebased on Geany's Git repository every now and then can be found at:
I gave it a quick try and in general it appears to work really great (i.e. I don't see any difference between this and the old version).
The only glitch I have noticed is that under Document->Indent Type, Document->Indent Width and Document->Set Line Endings all the items are selected with the radio selection circle. The fix is to disable "Active" for these items in the glade editor (not attaching patch because for some reason Glade changes also other elements in the XML file when I save it). Not sure if they were active before or there is some bug in the conversion from the old format.
Good catch, I didn't notice that. I've fixed it[1] using the defaults (I hope) on Geany 0.20 installed from the Debian repositories, hopefully those are correct (tabs, 4, and LF, respectively). It seems to be a Glade bug because even opening the original geany.glade file in Glade 3.8.0 causes all those items to become active, which is why I'm not 100% sure I've activated only the correct default items.
[1] https://github.com/codebrainz/geany/commit/df1de0767a3b3234a061ad4e0edf4796f...
Thanks, Matthew Brush
[...]
I'm really happy about this change. First we get rid of the horrible old glade editor and second it's the most important step towards making Geany compile under GTK 3. Thanks for your work!
Hi Jiri,
How much do you (or anyone) know about supporting both GTK2 and 3,
1. with the same source, 2. with the same binary, 3. differing platforms
The reason I ask is that my very preliminary evaluation is that
1. is possible but may need a bunch of #if sections :(, 2. is basically impossible >(, and 3. is unknown. >?
Cheers Lex
On 09/26/2011 04:08 AM, Lex Trotman wrote:
[...]
I'm really happy about this change. First we get rid of the horrible old glade editor and second it's the most important step towards making Geany compile under GTK 3. Thanks for your work!
Hi Jiri,
How much do you (or anyone) know about supporting both GTK2 and 3,
I'm responding as one of the "anyone" category :)
- with the same source,
- with the same binary,
- differing platforms
The reason I ask is that my very preliminary evaluation is that
- is possible but may need a bunch of #if sections :(,
- is basically impossible>(, and
- is unknown.>?
I didn't have time to dig up the actually commits and source involved, but for an example of a program supporting both, see: https://trac.transmissionbt.com/wiki/Changes
For an example a little more close to home, see Scintilla 2.29, which AFAIK, supports all GTK+ versions between 2.8 and 3.x :)
IMO, it would just be good to even just get the "Preparation in GTK+ 2.x" parts of the migration done in the very near future (from the Migration Guide). There's nothing mind-blowing in there, mostly just good GTK+/programming conventions.
That way when GTK+ 3 is more common, supporting it will be much easier, probably only requiring a few #if sections and some tweaks to the build system to detect the right majour version (ie. gtk+-3.0.pc over gtk+-2.0.pc and so on).
My $0.02.
Cheers, Matthew Brush
On Mon, Sep 26, 2011 at 13:08, Lex Trotman elextr@gmail.com wrote:
[...]
I'm really happy about this change. First we get rid of the horrible old glade editor and second it's the most important step towards making Geany compile under GTK 3. Thanks for your work!
Hi Jiri,
And I'm responding as a member of the Jiri category :-)
How much do you (or anyone) know about supporting both GTK2 and 3,
- with the same source,
- with the same binary,
- differing platforms
The reason I ask is that my very preliminary evaluation is that
- is possible but may need a bunch of #if sections :(,
Right. For the most common ones it would be best to create some utility functions that encapsulate the ifdefs so the ifdefs aren't everywhere.
- is basically impossible >(, and
Right, forget about it.
- is unknown. >?
No idea but I don't expect major issues once (1) is done.
In general it would be best just to try to substitute GTK version in configure, see what happens and start fixing the errors. I'm really tempted to try it myself but I'm not sure if I'll have enough time for that in the following few months. Also for changes like that it would be better to have git in place for easier merges once the work is done.
My personal feeling is that the sooner some support for GTK 3 is added, the better. Of course first, until it is stable and working as expected, it could be an experimental configure option which ordinary mortals would be discouraged to use. Meanwhile thanks to the ifdefs the old GTK 2 code should work as before. And maybe the conversion will be quite easy - it's just you never know unless you try it, so it's better to try it to know :-).
Jiri
On 09/26/2011 09:15 AM, Jiří Techet wrote:
In general it would be best just to try to substitute GTK version in configure, see what happens and start fixing the errors. I'm really tempted to try it myself but I'm not sure if I'll have enough time for that in the following few months. Also for changes like that it would be better to have git in place for easier merges once the work is done.
My personal feeling is that the sooner some support for GTK 3 is added, the better. Of course first, until it is stable and working as expected, it could be an experimental configure option which ordinary mortals would be discouraged to use. Meanwhile thanks to the ifdefs the old GTK 2 code should work as before. And maybe the conversion will be quite easy - it's just you never know unless you try it, so it's better to try it to know :-).
I did start a little bit with this in my geany repository.
Some observations:
1) Need to get rid of direct access of struct members[1].
2) Geany should support at minimum GTK+ 2.18 so that we can use gtk_widget_get_allocation() if we want to (cleanly) pass GSEAL_ENABLE builds. This actually wouldn't be needed strictly for GTK+ 3 since I think the old size allocation stuff is entirely gone.
3) The GeanyWrapLabel, I'm fairly sure can be #if'd out entirely for GTK+ 3.
4) The gdkkeysyms.h thing is easily solved by adding a #if to include gdkkeysyms-compat.h when using GTK+ 3.0.
5) Need to upgrade to Scintilla 2.29[2] since it supports GTK+ 3.0 (IIRC it still supports down to GTK+ 2.8 as well).
6) As you said, the configure.ac would need and option to enable this, to switch the package checks for gtk+-3.0 as well as another place where it collects the version of gtk+-2.0 using pkg-config.
7) Probably lots of other stuff I haven't discovered yet, since I haven't actually got Geany to build with GTK+ 3 yet.
In my opinion, I don't think it would *too* difficult to support GTK+ 2.1x all the way through 3.x at the same time.
[1] https://github.com/codebrainz/geany/commit/d2ba07b5ae9153f937adcb00337a66a30... [2] https://github.com/codebrainz/geany/commit/35e21eb65d4559685461007e1f39a75ef...
Cheers, Matthew Brush
Thanks Matthew, Jiri,
I was not after doing GTK3 it immediately, just trying to see if there were things being done in moving to gtkbuilder that might need to be undone later, and could we avoid that.
From both your comments it appears to be no extra work, gtkbuilder is
purely a step on the way to gtk3. Thats good, its a big monolithic change all ready. It is good it doesn't need to grow.
IIUC gtk3 ready migrations can then happen in small pieces afterwards. The smaller the resolution the more useful git blame is :)
Cheers Lex
On Sun, 25 Sep 2011 01:53:38 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
I've also taken the liberty of porting the Terminal/VTE preferences UI to the new Glade 3 format rather than being hard-coded. IIUC if the VTE/terminal is not enabled for whatever reason, the "Terminal" tab in the preferences dialog just won't be shown.
When we upgrade (someday) to 2.16, why not make VTE a compile time option only? I can understand why somebody would like to compile Geany without vte support, but since all novadays gtk+ terminal emulators are based on vte, making it a run-time option seems like overkill to me. It was a good thing, several years ago...
That will require some work, of course: replacing if (vf->func != NULL), cleaning up the vte_info and vc checks. I volunteer.
On 26 September 2011 01:26, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Sun, 25 Sep 2011 01:53:38 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
I've also taken the liberty of porting the Terminal/VTE preferences UI to the new Glade 3 format rather than being hard-coded. IIUC if the VTE/terminal is not enabled for whatever reason, the "Terminal" tab in the preferences dialog just won't be shown.
When we upgrade (someday) to 2.16, why not make VTE a compile time option only? I can understand why somebody would like to compile Geany without vte support, but since all novadays gtk+ terminal emulators are based on vte, making it a run-time option seems like overkill to me. It was a good thing, several years ago...
Hey Dimitar,
The problem with this is that means that all binary packages now depend on vte. If you might want to compile it out, then you might not want to install it.
Or there would need to be several binary packages, with and without VTE compiled in which is more maintenance.
With the runtime check VTE does not need to be installed.
Cheers Lex
That will require some work, of course: replacing if (vf->func != NULL), cleaning up the vte_info and vc checks. I volunteer.
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 09/25/2011 07:33 PM, Lex Trotman wrote:
On 26 September 2011 01:26, Dimitar Zhekovdimitar.zhekov@gmail.com wrote:
On Sun, 25 Sep 2011 01:53:38 -0700 Matthew Brushmbrush@codebrainz.ca wrote:
I've also taken the liberty of porting the Terminal/VTE preferences UI to the new Glade 3 format rather than being hard-coded. IIUC if the VTE/terminal is not enabled for whatever reason, the "Terminal" tab in the preferences dialog just won't be shown.
When we upgrade (someday) to 2.16, why not make VTE a compile time option only? I can understand why somebody would like to compile Geany without vte support, but since all novadays gtk+ terminal emulators are based on vte, making it a run-time option seems like overkill to me. It was a good thing, several years ago...
Hey Dimitar,
The problem with this is that means that all binary packages now depend on vte. If you might want to compile it out, then you might not want to install it.
Or there would need to be several binary packages, with and without VTE compiled in which is more maintenance.
With the runtime check VTE does not need to be installed.
One thing that would be cool with the runtime loading of VTE is if it could gracefully handle missing symbols in libvte. I don't know if this is possible with GModule/dlopen, but if it is, it would be great to implement this.
For example, I'm testing Geany with GTK+ 2.16 and when it goes to load the VTE, it loads the system one that was compiled against GTK+ 2.24 and Geany crashes with the output:
/opt/geany-2.16/bin/geany: symbol lookup error: /usr/lib/libvte.so.9: undefined symbol: gtk_widget_set_can_focus
To make Geany run, you have to use the `-t` option to disable the terminal or install a libvte compiled against the same GTK+ version as Geany and specify its path with the `--vte-lib` option. It would be nice to be able to handle such a case of missing symbols and just disable the VTE automatically, even though it might not be experienced too frequently on a typical system.
Cheers, Matthew Brush
On Mon, 26 Sep 2011 12:33:30 +1000 Lex Trotman elextr@gmail.com wrote:
On 26 September 2011 01:26, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
When we upgrade (someday) to 2.16, why not make VTE a compile time option only? I can understand why somebody would like to compile Geany without vte support, but since all novadays gtk+ terminal emulators are based on vte, making it a run-time option seems like overkill to me. It was a good thing, several years ago...
The problem with this is that means that all binary packages now depend on vte.
Of course. However:
- when using binary packages, you should be prepared for some extra dependencies - again, all novadays gtk+ terminal emulators are libvte based.
If you might want to compile it out, then you might not want to install it.
Hmmm... Just how many programs have you seen that can be compiled --with-libfoo but started without libfoo? Aside from Geany, I only know of mplayer which can be compiled with win32 dll-s support, but started even if no dll-s are present, for obvious reasons. If you want to install it out, compile it out.
Or there would need to be several binary packages, with and without VTE compiled in which is more maintenance.
No sane package maintainer will bother. When checking the various preferences or something, I found 2 crashes when vte is compiled but not loaded. That kind of hints how many people use Geany with vte compiled but not installed...
With the runtime check VTE does not need to be installed.
Indeed. :) Let's hope there aren't any more crashes. Not that anyone will notice them.
Hi Dimitar,
[...]
When checking the various preferences or something, I found 2 crashes when vte is compiled but not loaded. That kind of hints how many people use Geany with vte compiled but not installed...
With the runtime check VTE does not need to be installed.
Indeed. :) Let's hope there aren't any more crashes. Not that anyone will notice them.
Ok, if thats the case lets ignore the possibility of runtime loading and just compile it in/out.
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 29 Sep 2011 09:16:26 +1000 Lex Trotman elextr@gmail.com wrote:
Hi Dimitar,
[...]
When checking the various preferences or something, I found 2 crashes when vte is compiled but
Ok, if thats the case lets ignore the possibility of runtime loading and just compile it in/out.
These were fixed, so don't worry. But I only checked the preferences related stuff (for xsm perhaps?), not the entire code.