Hi all,
According to the recent discussions on the mailing list, its sounds like we could safely require GTK+ >= 2.18 and still support a lot of enterprise/LTS/legacy distros.
You might've noticed I pushed my gtkbuilder branch into geany/geany. To use this requires GTK+ 2.16 since it seems this is where lots of the GtkWidgets that Geany uses started to implement the GtkBuildable interface. This is at least according to what I read and the complaints from Glade 3.
I've also been working on getting rid of some of the uses of sealed members (ex. widget->window as opposed to gtk_widget_get_window(widget)). It seems many of the accessor functions were added between 2.12 and 2.18. One of the functions that comes to mind that needs 2.18 and could be used in several places in Geany is gtk_widget_get_allocation().
So I was wondering if anyone was opposed to going from GTK+ 2.12 to 2.18 as the minimum supported GTK+ version. IMO, if we are going to raise the version this release cycle, it makes sense to do so sooner rather than later to maximize the time for finding and fixing bugs and so on.
As a side topic; is there any way we can automate parts of changing the GTK+/GLib version numbers in all the various affected files? I was thinking maybe a small Python/Perl script or Autoconf substitution or something like this. It's just an idea that came to mind, it might be stupid/pointless.
@Enrico: How much trouble does this cause for the win32 builds? Is it just changing the Waf/makefile.win32 files and then packaging a newer GTK+ binary pack next release?
Cheers, Matthew Brush
[...]
So I was wondering if anyone was opposed to going from GTK+ 2.12 to 2.18 as the minimum supported GTK+ version. IMO, if we are going to raise the version this release cycle, it makes sense to do so sooner rather than later to maximize the time for finding and fixing bugs and so on.
Makes sense, no problem on Linux.
As a side topic; is there any way we can automate parts of changing the GTK+/GLib version numbers in all the various affected files? I was thinking maybe a small Python/Perl script or Autoconf substitution or something like this. It's just an idea that came to mind, it might be stupid/pointless.
@Enrico: How much trouble does this cause for the win32 builds? Is it just changing the Waf/makefile.win32 files and then packaging a newer GTK+ binary pack next release?
Are we sure that version works fine with the gtkbuilder version of Geany?
Cheers Lex
On 12/10/2011 02:58, Matthew Brush wrote:
Hi all,
According to the recent discussions on the mailing list, its sounds like we could safely require GTK+ >= 2.18 and still support a lot of enterprise/LTS/legacy distros.
You might've noticed I pushed my gtkbuilder branch into geany/geany. To use this requires GTK+ 2.16 since it seems this is where lots of the GtkWidgets that Geany uses started to implement the GtkBuildable interface. This is at least according to what I read and the complaints from Glade 3.
I've also been working on getting rid of some of the uses of sealed members (ex. widget->window as opposed to gtk_widget_get_window(widget)). It seems many of the accessor functions were added between 2.12 and 2.18. One of the functions that comes to mind that needs 2.18 and could be used in several places in Geany is gtk_widget_get_allocation().
OTOH, those functions are trivial to support on < 2.18, if there were a reason to prefer lower versions. If there's not too many.
I would say Glade 3 support is important, but I'm not sure how important GTK 3 support is yet.
So I was wondering if anyone was opposed to going from GTK+ 2.12 to 2.18 as the minimum supported GTK+ version. IMO, if we are going to raise the version this release cycle, it makes sense to do so sooner rather than later to maximize the time for finding and fixing bugs and so on.
From my own POV I would prefer lower versions for now - I have 2.16 on my main machine. I could update but I'm still reeling a little from the github switch ;-)
So I would go for 2.16 overall if this brings us Glade 3 support.
Am 12.10.2011 16:04, schrieb Nick Treleaven:
So I would go for 2.16 overall if this brings us Glade 3 support.
Also we have to think twice because of the Gtk/Windows item brought up earlier. (not sure atm what was the outcome)
Cheers, Frank
On 11-10-12 07:07 AM, Frank Lanitz wrote:
Am 12.10.2011 16:04, schrieb Nick Treleaven:
So I would go for 2.16 overall if this brings us Glade 3 support.
Also we have to think twice because of the Gtk/Windows item brought up earlier. (not sure atm what was the outcome)
From what I gather, the good versions of GTK+ for Windows are 2.16, 2.22 and 2.24. Presumably we could use one of the later versions.
Cheers, Matthew Brush
On 11-10-12 07:04 AM, Nick Treleaven wrote:
On 12/10/2011 02:58, Matthew Brush wrote:
I've also been working on getting rid of some of the uses of sealed members (ex. widget->window as opposed to gtk_widget_get_window(widget)). It seems many of the accessor functions were added between 2.12 and 2.18. One of the functions that comes to mind that needs 2.18 and could be used in several places in Geany is gtk_widget_get_allocation().
OTOH, those functions are trivial to support on < 2.18, if there were a reason to prefer lower versions. If there's not too many.
There's lots :) [1]
So I was wondering if anyone was opposed to going from GTK+ 2.12 to 2.18 as the minimum supported GTK+ version. IMO, if we are going to raise the version this release cycle, it makes sense to do so sooner rather than later to maximize the time for finding and fixing bugs and so on.
From my own POV I would prefer lower versions for now - I have 2.16 on my main machine. I could update but I'm still reeling a little from the github switch ;-)
So the answer to my question in the other thread about what specifically sets the minimum GTK+ version Geany supports is: Whatever Nick is running :)
So I would go for 2.16 overall if this brings us Glade 3 support.
It should, but I haven't thoroughly tested it with GTK+ 2.16 yet. Did you try the gtkbuilder branch yet on your 2.16 install by any chance?
Anyway, I won't push for GTK+ 2.18 any more if some core Geany devs are against it.
Cheers, Matthew Brush
[1] https://github.com/codebrainz/geany/commit/06e27060fd5022d22160d51ca62c3601f...
On 13/10/2011 00:55, Matthew Brush wrote:
On 11-10-12 07:04 AM, Nick Treleaven wrote:
On 12/10/2011 02:58, Matthew Brush wrote:
I've also been working on getting rid of some of the uses of sealed members (ex. widget->window as opposed to gtk_widget_get_window(widget)). It seems many of the accessor functions were added between 2.12 and 2.18. One of the functions that comes to mind that needs 2.18 and could be used in several places in Geany is gtk_widget_get_allocation().
OTOH, those functions are trivial to support on < 2.18, if there were a reason to prefer lower versions. If there's not too many.
There's lots :) [1] [1]
https://github.com/codebrainz/geany/commit/06e27060fd5022d22160d51ca62c3601f...
That includes changes that work on GTK 2.0 - what I meant is how many functions are added in 2.18 that aren't in 2.16 that could be included with:
#if gtk < 2.18 bar gtk_foo_get_bar(){return foo->bar;} #endif
I didn't look at the diff much because it didn't really answer this.
So I was wondering if anyone was opposed to going from GTK+ 2.12 to 2.18 as the minimum supported GTK+ version. IMO, if we are going to raise the version this release cycle, it makes sense to do so sooner rather than later to maximize the time for finding and fixing bugs and so on.
From my own POV I would prefer lower versions for now - I have 2.16 on my main machine. I could update but I'm still reeling a little from the github switch ;-)
So the answer to my question in the other thread about what specifically sets the minimum GTK+ version Geany supports is: Whatever Nick is running :)
Not necessarily, I could upgrade as I'm on Windows, but for now I'd prefer not to.
A more important issue is maximising who can contribute to Geany, so it's good to not require anything released in e.g. the last two years without good reason. I know 2.16 is probably before that though.
So I would go for 2.16 overall if this brings us Glade 3 support.
It should, but I haven't thoroughly tested it with GTK+ 2.16 yet. Did you try the gtkbuilder branch yet on your 2.16 install by any chance?
No, I haven't tried git branching yet. I'll let you know when I do.
Anyway, I won't push for GTK+ 2.18 any more if some core Geany devs are against it.
I'm not completely against it but just want to make sure it brings real benefits for us.
On 13/10/2011 12:53, Nick Treleaven wrote:
On 13/10/2011 00:55, Matthew Brush wrote:
So I would go for 2.16 overall if this brings us Glade 3 support.
It should, but I haven't thoroughly tested it with GTK+ 2.16 yet. Did you try the gtkbuilder branch yet on your 2.16 install by any chance?
No, I haven't tried git branching yet. I'll let you know when I do.
Tried it earlier, seems to build against 2.16 (I actually have a newer runtime) and run OK after I applied some fixes. I didn't really test it much besides showing the Prefs dialog. Anything in particular that needs testing?
I did get a warning: Gtk WARNING : Could not find signal handler 'on_term_font_set'
On 14/10/2011 15:38, Nick Treleaven wrote:
I did get a warning: Gtk WARNING : Could not find signal handler 'on_term_font_set'
This is because on_term_font_set is not defined unless VTE support is compiled in (on Windows it's disabled).
On 11-10-14 07:38 AM, Nick Treleaven wrote:
On 13/10/2011 12:53, Nick Treleaven wrote:
On 13/10/2011 00:55, Matthew Brush wrote:
So I would go for 2.16 overall if this brings us Glade 3 support.
It should, but I haven't thoroughly tested it with GTK+ 2.16 yet. Did you try the gtkbuilder branch yet on your 2.16 install by any chance?
No, I haven't tried git branching yet. I'll let you know when I do.
Tried it earlier, seems to build against 2.16 (I actually have a newer runtime) and run OK after I applied some fixes. I didn't really test it much besides showing the Prefs dialog. Anything in particular that needs testing?
Hi Nick,
There's seems to be a problem applying, saving and restoring the background and foreground colours for the VTE, I couldn't figure it out last time I looked. Not sure if you can have a peek at this, but I guess you'll need to boot into Linux to test.
Thanks for testing and fixes so far, I'm about to finish fixing the other issues you noted.
Cheers, Matthew Brush
On 11-10-14 08:18 PM, Matthew Brush wrote:
There's seems to be a problem applying, saving and restoring the background and foreground colours for the VTE, I couldn't figure it out last time I looked. Not sure if you can have a peek at this, but I guess you'll need to boot into Linux to test.
Never mind, it seems I forgot to connect the signal handlers for the fg/bg colour buttons `color-set` signals. The issues we've discussed so far should all be fixed now in the `gtkbuilder` branch.
Cheers, Matthew Brush
On 15/10/2011 05:07, Matthew Brush wrote:
On 11-10-14 08:18 PM, Matthew Brush wrote:
There's seems to be a problem applying, saving and restoring the background and foreground colours for the VTE, I couldn't figure it out last time I looked. Not sure if you can have a peek at this, but I guess you'll need to boot into Linux to test.
Never mind, it seems I forgot to connect the signal handlers for the fg/bg colour buttons `color-set` signals. The issues we've discussed so far should all be fixed now in the `gtkbuilder` branch.
Thanks, looks good.
On 11-10-14 07:38 AM, Nick Treleaven wrote:
On 13/10/2011 12:53, Nick Treleaven wrote:
On 13/10/2011 00:55, Matthew Brush wrote:
So I would go for 2.16 overall if this brings us Glade 3 support.
It should, but I haven't thoroughly tested it with GTK+ 2.16 yet. Did you try the gtkbuilder branch yet on your 2.16 install by any chance?
No, I haven't tried git branching yet. I'll let you know when I do.
Tried it earlier, seems to build against 2.16 (I actually have a newer runtime) and run OK after I applied some fixes. I didn't really test it much besides showing the Prefs dialog. Anything in particular that needs testing?
I also noticed some issues with defaults in the project dialog where some stuff doesn't have a default and some of the combo boxes have two columns showing so it looks like:
"Item 1 Item 1" "Item 2 Item 2"
IMO, it would *really* be nice to get all of the Project dialog ported to GtkBuilder since currently only the Editor and Indentation tabs are in GtkBuilder, the "Project" tab and the Build tab are both hard-coded and added to the dialog at runtime it seems.
Also, I think we should discuss a better organization for the tabs in the Project dialog, but first I'd like to get everything existing working.
I'll follow up when that happends.
Cheers, Matthew Brush
On 18 October 2011 10:17, Matthew Brush mbrush@codebrainz.ca wrote:
On 11-10-14 07:38 AM, Nick Treleaven wrote:
On 13/10/2011 12:53, Nick Treleaven wrote:
On 13/10/2011 00:55, Matthew Brush wrote:
So I would go for 2.16 overall if this brings us Glade 3 support.
It should, but I haven't thoroughly tested it with GTK+ 2.16 yet. Did you try the gtkbuilder branch yet on your 2.16 install by any chance?
No, I haven't tried git branching yet. I'll let you know when I do.
Tried it earlier, seems to build against 2.16 (I actually have a newer runtime) and run OK after I applied some fixes. I didn't really test it much besides showing the Prefs dialog. Anything in particular that needs testing?
I also noticed some issues with defaults in the project dialog where some stuff doesn't have a default and some of the combo boxes have two columns showing so it looks like:
"Item 1 Item 1" "Item 2 Item 2"
IMO, it would *really* be nice to get all of the Project dialog ported to GtkBuilder since currently only the Editor and Indentation tabs are in GtkBuilder, the "Project" tab and the Build tab are both hard-coded and added to the dialog at runtime it seems.
Hi Matthew,
Yes, the build tab is generated at runtime because it has variable length (set by the number_xx_menu_items prefs).
Possibly it could be a treeview, but that would change the whole operation of the build tabs and would need discussion with Nick who has strong ideas on the subject :)
Cheers Lex
Also, I think we should discuss a better organization for the tabs in the Project dialog, but first I'd like to get everything existing working.
I'll follow up when that happends.
Cheers, Matthew Brush _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 11-10-17 04:27 PM, Lex Trotman wrote:
On 18 October 2011 10:17, Matthew Brushmbrush@codebrainz.ca wrote:
On 11-10-14 07:38 AM, Nick Treleaven wrote:
On 13/10/2011 12:53, Nick Treleaven wrote:
On 13/10/2011 00:55, Matthew Brush wrote:
So I would go for 2.16 overall if this brings us Glade 3 support.
It should, but I haven't thoroughly tested it with GTK+ 2.16 yet. Did you try the gtkbuilder branch yet on your 2.16 install by any chance?
No, I haven't tried git branching yet. I'll let you know when I do.
Tried it earlier, seems to build against 2.16 (I actually have a newer runtime) and run OK after I applied some fixes. I didn't really test it much besides showing the Prefs dialog. Anything in particular that needs testing?
I also noticed some issues with defaults in the project dialog where some stuff doesn't have a default and some of the combo boxes have two columns showing so it looks like:
"Item 1 Item 1" "Item 2 Item 2"IMO, it would *really* be nice to get all of the Project dialog ported to GtkBuilder since currently only the Editor and Indentation tabs are in GtkBuilder, the "Project" tab and the Build tab are both hard-coded and added to the dialog at runtime it seems.
Hi Matthew,
Yes, the build tab is generated at runtime because it has variable length (set by the number_xx_menu_items prefs).
Possibly it could be a treeview, but that would change the whole operation of the build tabs and would need discussion with Nick who has strong ideas on the subject :)
+1. I actually started tinkering with making it a treeview in Glade, since it makes way more sense to not have a hardcoded number and types of build commands, but of course as we discussed before, there needs to be a fixed number of commands at startup due to the limitations in the keybinding system.
Anyway, for now, we could add the whole UI into Glade except the dynamic part and just append/insert rows for more commands at run-time for the parts that change. At least 95% of it would go into the UI file.
Cheers, Matthew Brush
On 18/10/2011 00:36, Matthew Brush wrote:
On 11-10-17 04:27 PM, Lex Trotman wrote:
On 18 October 2011 10:17, Matthew Brushmbrush@codebrainz.ca wrote:
I also noticed some issues with defaults in the project dialog where some stuff doesn't have a default and some of the combo boxes have two columns showing so it looks like:
"Item 1 Item 1" "Item 2 Item 2"
IMO, it would *really* be nice to get all of the Project dialog ported to GtkBuilder since currently only the Editor and Indentation tabs are in GtkBuilder, the "Project" tab and the Build tab are both hard-coded and added to the dialog at runtime it seems.
Hi Matthew,
Yes, the build tab is generated at runtime because it has variable length (set by the number_xx_menu_items prefs).
Possibly it could be a treeview, but that would change the whole operation of the build tabs and would need discussion with Nick who has strong ideas on the subject :)
Not really, I'm just opposed to replacing groups of commands with a list of commands as I think this is worse usability.
I think a treeview for each command group wouldn't really change things and might look better. Is there a way to show a label with mnemonic in a treeview column? Not crucial but nice to have.
+1. I actually started tinkering with making it a treeview in Glade, since it makes way more sense to not have a hardcoded number and types of build commands, but of course as we discussed before, there needs to be a fixed number of commands at startup due to the limitations in the keybinding system.
Not necessarily, but sort of. Keybindings that map to a non existent command could just do nothing.
Anyway, for now, we could add the whole UI into Glade except the dynamic part and just append/insert rows for more commands at run-time for the parts that change. At least 95% of it would go into the UI file.
Sounds good, but maybe it's best to wait until after the merge into master. I think branches should stay focused on one thing; that sounds like a bigger change.
On 18/10/2011 17:30, Nick Treleaven wrote:
On 18/10/2011 00:36, Matthew Brush wrote:
On 11-10-17 04:27 PM, Lex Trotman wrote:
Yes, the build tab is generated at runtime because it has variable length (set by the number_xx_menu_items prefs).
Possibly it could be a treeview, but that would change the whole operation of the build tabs and would need discussion with Nick who has strong ideas on the subject :)
Not really, I'm just opposed to replacing groups of commands with a list of commands as I think this is worse usability.
I think a treeview for each command group wouldn't really change things and might look better. Is there a way to show a label with mnemonic in a treeview column? Not crucial but nice to have.
Actually one treeview would be better, but I think the error regex fields would need to be separate from the tree. Perhaps grouped underneath it. It could look something like:
Current filetype: C
Label Command Directory Reset ----- ------- --------- ----- / Filetype build commands ... / Independent build commands ... / Execute commands ...
Error regular expressions: Filetype: [ ] Independent: [ ]
I've added a label for current filetype above (this could be done separately). This is to avoid repeating the filetype name in multiple places, and I think it's clearer.
On 19 October 2011 23:43, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 18/10/2011 17:30, Nick Treleaven wrote:
On 18/10/2011 00:36, Matthew Brush wrote:
On 11-10-17 04:27 PM, Lex Trotman wrote:
Yes, the build tab is generated at runtime because it has variable length (set by the number_xx_menu_items prefs).
Possibly it could be a treeview, but that would change the whole operation of the build tabs and would need discussion with Nick who has strong ideas on the subject :)
Not really, I'm just opposed to replacing groups of commands with a list of commands as I think this is worse usability.
I think a treeview for each command group wouldn't really change things and might look better. Is there a way to show a label with mnemonic in a treeview column? Not crucial but nice to have.
Actually one treeview would be better, but I think the error regex fields would need to be separate from the tree. Perhaps grouped underneath it. It could look something like:
Current filetype: C
Label Command Directory Reset ----- ------- --------- ----- / Filetype build commands ... / Independent build commands ... / Execute commands ...
Error regular expressions: Filetype: [ ] Independent: [ ]
WARNING, WARNING !!!! Thats exactly what I was thinking Nick, we AGREE!!!! :D
I've added a label for current filetype above (this could be done separately). This is to avoid repeating the filetype name in multiple places, and I think it's clearer.
Good idea.
And of course the extra non-filetype execute group we want to add just tacks on the end :)
Now to get enough time.
Cheers Lex
Le 13/10/2011 01:55, Matthew Brush a écrit :
On 11-10-12 07:04 AM, Nick Treleaven wrote:
On 12/10/2011 02:58, Matthew Brush wrote:
I've also been working on getting rid of some of the uses of sealed members (ex. widget->window as opposed to gtk_widget_get_window(widget)). It seems many of the accessor functions were added between 2.12 and 2.18. One of the functions that comes to mind that needs 2.18 and could be used in several places in Geany is gtk_widget_get_allocation().
OTOH, those functions are trivial to support on < 2.18, if there were a reason to prefer lower versions. If there's not too many.
There's lots :) [1]
As Nick said, your link doesn't tell which ones requires 2.18 ;) IMO it's not too hard to create a "compat" header that would define the required accessors for version where they're missing. It's quite a boring work but nothing complicated.
Anyway AFAIK there are lot of accessors that came in 2.24, and we probably don't want to require bleeding-edge GTK2.
So I was wondering if anyone was opposed to going from GTK+ 2.12 to 2.18 as the minimum supported GTK+ version. IMO, if we are going to raise the version this release cycle, it makes sense to do so sooner rather than later to maximize the time for finding and fixing bugs and so on.
From my own POV I would prefer lower versions for now - I have 2.16 on my main machine. I could update but I'm still reeling a little from the github switch ;-)
So the answer to my question in the other thread about what specifically sets the minimum GTK+ version Geany supports is: Whatever Nick is running :)
So I would go for 2.16 overall if this brings us Glade 3 support.
It should, but I haven't thoroughly tested it with GTK+ 2.16 yet. Did you try the gtkbuilder branch yet on your 2.16 install by any chance?
Anyway, I won't push for GTK+ 2.18 any more if some core Geany devs are against it.
I'm not against any GTK version (heh, I personally have 2.24 and 3.0 anyway ^^), but I think we shouldn't bump for no good reason. If we need a new widget, or a new feature, OK, but if it's for 1 or 2 accessors and we anyway need some more that are only in even more recent versions, it seems a bit pointless to me.
So 2.16 for GtkBuilder, yes. 2.18... I'm not sure, it depends on what is the rationale for it.
Regards, Colomban
On 11-10-17 09:22 AM, Colomban Wendling wrote:
I'm not against any GTK version (heh, I personally have 2.24 and 3.0 anyway ^^), but I think we shouldn't bump for no good reason. If we need a new widget, or a new feature, OK, but if it's for 1 or 2 accessors and we anyway need some more that are only in even more recent versions, it seems a bit pointless to me.
So 2.16 for GtkBuilder, yes. 2.18... I'm not sure, it depends on what is the rationale for it.
From my own P.O.V. it's: a) 2.18 has the rest of the accessors we need (though many also came in 2.14 & 2.16, none that we use came later than 2.18 AFAIK) and b) that the GtkInfoBar has a few uses in Geany where a dialog is too "strong" and the statusbar is too "weak". But it's honestly not a huge deal, I just think if there's any chance that we'll be bumping GTK+ to 2.18 before the next release, we should really consider doing it ASAP. Otherwise, 2.16 is fine if it allows us to get GtkBuilder stuff working.
Cheers, Matthew Brush