Hello,
It took me a little while to find the Search preferences. I did not expect them to be filed under 'General' -> 'Miscellaneous'.
From a usability perspective: In my attempt to configure search, I first
looked in "Editor", and then "Interface".
I was getting very irritated with the message "<keyword> not found. Wrap search and try again?". It happened every time I searched for something while my cursor was near the bottom of a document. Now I am finding that the "Always wrap search and hide the Find dialog" setting is insufficient, since my personal preference is to always wrap search, but keep the find dialog open.
So may I please request the following modifications to search:
- Move the 'Search' preferences to 'Editor' -> 'Search & Replace', instead of 'General' -> 'Miscellaneous' - Remove the "Always wrap search and hide the Find dialog" setting. - Add a 'Wrap search' checkbox to the Find dialog, below the 'Close dialog' checkbox. - Make 'Wrap search' checked by default.
Best regards, Nathan B
- Move the 'Search' preferences to 'Editor' -> 'Search & Replace', instead of 'General' -> 'Miscellaneous'
- Remove the "Always wrap search and hide the Find dialog" setting.
- Add a 'Wrap search' checkbox to the Find dialog, below the 'Close dialog' checkbox.
- Make 'Wrap search' checked by default.
Some of these points have been discussed, but not concluded, in the following SourceForge feature requests:
* https://sourceforge.net/tracker/?func=detail&aid=2962018&group_id=15... * https://sourceforge.net/tracker/?func=detail&aid=2877992&group_id=15...
Best regards, Nathan
On Sat, 3 Dec 2011 17:24:45 +0800 Nathan Broadbent nathan.f77@gmail.com wrote:
my personal preference is to always wrap search, but keep the find dialog open.
This is your personal preference only.
So may I please request the following modifications to search:
- Move the 'Search' preferences to 'Editor' -> 'Search & Replace',
instead of 'General' -> 'Miscellaneous'
It took you a little while to find these preferences, and Geany has a manual anyway.
- Remove the "Always wrap search and hide the Find dialog" setting.
What about the people who prefer to always hide the open dialog?
- Add a 'Wrap search' checkbox to the Find dialog, below the 'Close
dialog' checkbox.
- Make 'Wrap search' checked by default.
And that'll irritate anyone who prefers not to wrap, and has to uncheck 'Wrap search' any time (s)he starts Geany.
There is one, and only one thing, that is unquestionably better IMHO: separate [ ] "Always wrap search and hide the Find dialog" into [ ] "Always wrap search" and [ ] "Hide the Find dialog". It can even be implemented in backwards-compatible way, so if the lead developers approve, I'll give it a try.
Le 03/12/2011 20:56, Dimitar Zhekov a écrit :
On Sat, 3 Dec 2011 17:24:45 +0800 Nathan Broadbent nathan.f77@gmail.com wrote:
my personal preference is to always wrap search, but keep the find dialog open.
This is your personal preference only.
So may I please request the following modifications to search:
- Move the 'Search' preferences to 'Editor' -> 'Search & Replace',
instead of 'General' -> 'Miscellaneous'
I agree that Miscellaneous is not necessarily the most obvious, but there are so few Search & Replace settings that giving them a whole tab may make them a little easier to find, but also a little harder to navigate the dialog.
Also, putting it in Editor makes no sense to me, or then we'd need to have almost everything under Editor (some of Interface like tabs, Editor, Files, etc.)
I'm not really against having a General -> Search tab, but I'm not sure having a tab with 3/4 settings only is so much better.
- Remove the "Always wrap search and hide the Find dialog" setting.
What about the people who prefer to always hide the open dialog?
+1, that's a feature we have and people use, I don't think we should remove it.
- Add a 'Wrap search' checkbox to the Find dialog, below the 'Close
dialog' checkbox.
This makes no sense to me to have it with "close dialog" since that last option is only useful to have in the dialog (and only shown/used) when "finding all", and here wrapping search doesn't count.
Having "wrap search" here is not useful IMO since it'd need the user to click a checkbox not to click a button when a dialog pops... ouch. IMO, it only moves the problem, doesn't solve anything. The general "wrap search" however makes better sense.
- Make 'Wrap search' checked by default.
And that'll irritate anyone who prefers not to wrap, and has to uncheck 'Wrap search' any time (s)he starts Geany.
Yep, that's a default value that will probably please 50% users and annoy the other 50%. A pref's good, but changing the default doesn't make much sense if you ain't got no well-done statistics about most spread user opinion.
There is one, and only one thing, that is unquestionably better IMHO: separate [ ] "Always wrap search and hide the Find dialog" into [ ] "Always wrap search" and [ ] "Hide the Find dialog". It can even be implemented in backwards-compatible way, so if the lead developers approve, I'll give it a try.
Yep, this sounds sensible to me. It'd be better flexible and I can understand somebody was one and not the other. So yeah, go ahead :)
Regards, Colomban
my personal preference is to always wrap search, but keep the find dialog open.
This is your personal preference only.
Yes, I was just saying that I would like my personal preference to be possible
I'm not really against having a General -> Search tab, but I'm not sure having a tab with 3/4 settings only is so much better.
Ok, thats fine
- Remove the "Always wrap search and hide the Find dialog" setting.
What about the people who prefer to always hide the open dialog?
+1, that's a feature we have and people use, I don't think we should remove it.
Sorry, I wasn't suggesting to remove the feature, just to make it more customizable.
- Make 'Wrap search' checked by default.
And that'll irritate anyone who prefers not to wrap, and has to uncheck 'Wrap search' any time (s)he starts Geany.
Yep, that's a default value that will probably please 50% users and annoy the other 50%. A pref's good, but changing the default doesn't make much sense if you ain't got no well-done statistics about most spread user opinion.
The reason I thought of putting the 'wrap search' checkbox on the Find dialog, is that the 'close dialog' checkbox does remember it's state after closing and restarting Geany. So a user would only ever need to change it once.
There is one, and only one thing, that is unquestionably better IMHO: separate [ ] "Always wrap search and hide the Find dialog" into [ ] "Always wrap search" and [ ] "Hide the Find dialog". It can even be implemented in backwards-compatible way, so if the lead developers approve, I'll give it a try.
Yep, this sounds sensible to me. It'd be better flexible and I can understand somebody was one and not the other. So yeah, go ahead :)
That's fine too, I'd be very happy if I could just configure each setting separately.
Thanks very much for your responses!
Nathan
Le 04/12/2011 01:36, Nathan Broadbent a écrit :
- Make 'Wrap search' checked by default.
And that'll irritate anyone who prefers not to wrap, and has to uncheck 'Wrap search' any time (s)he starts Geany.
Yep, that's a default value that will probably please 50% users and annoy the other 50%. A pref's good, but changing the default doesn't make much sense if you ain't got no well-done statistics about most spread user opinion.
The reason I thought of putting the 'wrap search' checkbox on the Find dialog, is that the 'close dialog' checkbox does remember it's state after closing and restarting Geany. So a user would only ever need to change it once.
("close dialog" currently only closes the dialog for "find all" style options)
Hum, you mean displaying the "wrap search" prefs from the pref dialog in the find dialog too? Why not, but I'm afraid it'd make the dialog less readable for not much benefit.
Regards, Colomban
("close dialog" currently only closes the dialog for "find all" style options)
This is true. However, if you look at the "Add wrapped search" [1] feature request (which is still open), Nick Treleaven and Enrico Tröger had a conversation about changing this back in 2009:
2009-10-14 05:49:13 ntrel: I suppose we could make the option 'Always wrap' and then change the dialog 'close' checkbox to apply to all actions. Sound OK Enrico?
2009-10-21 10:30:46 eht16: Nick, yes, sounds good.
Hum, you mean displaying the "wrap search" prefs from the pref dialog in the find dialog too? Why not, but I'm afraid it'd make the dialog less readable for not much benefit.
Well, if the "Close dialog" checkbox did apply to all actions, and the "wrap search" checkbox was also on the Find dialog, then both of those settings wouldn't need to be in Preferences any more.. Because they would always be configurable on the Find dialog.
I'm a bit tired of the debate though, so I'm happy to just apply Dimitar's patch and close all of these feature request tickets :)
Regards, Nathan
[1] http://sourceforge.net/tracker/?func=detail&aid=2877992&group_id=153...
Le 04/12/2011 20:21, Nathan Broadbent a écrit :
("close dialog" currently only closes the dialog for "find all" style options)
This is true. However, if you look at the "Add wrapped search" [1] feature request (which is still open), Nick Treleaven and Enrico Tröger had a conversation about changing this back in 2009:
2009-10-14 05:49:13 ntrel: I suppose we could make the option 'Always wrap' and then change the dialog 'close' checkbox to apply to all actions. Sound OK Enrico?
2009-10-21 10:30:46 eht16: Nick, yes, sounds good.
Hum yeah, you make me remember I saw this the other day.
However I don't agree that "close" should apply to all actions if it's saved (and it should be saved), because my use-case wouldn't fit: I always have the "close" checked, but (almost) never want to close the dialog when I click "next".
What I think is that keeping the dialog when all results are in the message panel isn't really useful; but when searching with the find dialog I generally use the Next button.
And final use case that wouldn't fit is to "prepare" a complex search pattern (regex). I want to try it first to check it actually matches as I want, and then find all -- well OK, I do this more using replace dialog than search.
Hum, you mean displaying the "wrap search" prefs from the pref dialog in the find dialog too? Why not, but I'm afraid it'd make the dialog less readable for not much benefit.
Well, if the "Close dialog" checkbox did apply to all actions, and the "wrap search" checkbox was also on the Find dialog, then both of those settings wouldn't need to be in Preferences any more.. Because they would always be configurable on the Find dialog.
I'm a bit tired of the debate though, so I'm happy to just apply Dimitar's patch and close all of these feature request tickets :)
Well, so let's stop here and be happy with Dimitar's patch :)
Regards, Colomban
On Mon, 5 Dec 2011 03:21:45 +0800 Nathan Broadbent nathan.f77@gmail.com wrote:
2009-10-14 05:49:13 ntrel: I suppose we could make the option 'Always wrap' and then change the dialog 'close' checkbox to apply to all actions. Sound OK Enrico?
2009-10-21 10:30:46 eht16: Nick, yes, sounds good.
I'm glad they didn't make it. Sounds good, technically, but as Colomban pointed out, it's one thing to close the dialog after finding/marking all matches (very likely), and another to close it after the first or subsequent Next/Previous find.
I'm a bit tired of the debate though, so I'm happy to just apply Dimitar's patch and close all of these feature request tickets :)
You'll need to re-check the prefs after the patch is officially applied, they'll be in another group and renamed.
On Sun, 04 Dec 2011 00:48:40 +0100 Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 03/12/2011 20:56, Dimitar Zhekov a écrit :
There is one, and only one thing, that is unquestionably better IMHO: separate [ ] "Always wrap search and hide the Find dialog" into [...]
Yep, this sounds sensible to me. It'd be better flexible and I can understand somebody was one and not the other. So yeah, go ahead :)
It turned out to be quite easy, because the two meanings are actualy used separately...
It turned out to be quite easy, because the two meanings are actualy used separately...
-- E-gards: Jimmy
Thanks very much for the patch, it works great!
- Make 'Wrap search' checked by default.
And that'll irritate anyone who prefers not to wrap, and has to uncheck 'Wrap search' any time (s)he starts Geany.
Sorry, I wanted to suggest changing the default for the Geany installation. The user's preference would still be saved between sessions
Yep, that's a default value that will probably please 50% users and annoy the other 50%. A pref's good, but changing the default doesn't make much sense if you ain't got no well-done statistics about most spread user opinion.
I've tried to collect a few statistics... Here are my sources:
* Geany feature request - "search autowrap on by default" (http://sourceforge.net/tracker/?func=detail&aid=2962018&group_id=153... * Same feature request for the Bugzilla project (https://bugzilla.mozilla.org/show_bug.cgi?id=91520)
Votes for 'Wrap search' by default (11):
Nick Treleaven, John Levon, Blake Ross, Jesse Ruderman, Neil Becker, TGOS, Mike Stockman, Andrew Pimlott, Tom Schneider, realgrouchy, "search autowrap on by default" poster (anonymous)
Votes against 'Wrap search' by default (2):
timeless, Fred
Enrico Tröger was impartial, stating "I don't mind much, we can change the default."
Everything's up to you, but I do feel that this default would make search more friendly for new users.
Also, sorry to be all talk and no contribution yet... But I am currently working on a HAML lexer for Scintilla, as well as improvements to the TreeBrowser plugin.
Best regards, Nathan
Le 04/12/2011 16:13, Nathan Broadbent a écrit :
[...]
Yep, that's a default value that will probably please 50% users and annoy the other 50%. A pref's good, but changing the default doesn't make much sense if you ain't got no well-done statistics about most spread user opinion.
I've tried to collect a few statistics... Here are my sources:
- Geany feature request - "search autowrap on by default"
(http://sourceforge.net/tracker/?func=detail&aid=2962018&group_id=153...
- Same feature request for the Bugzilla project
(https://bugzilla.mozilla.org/show_bug.cgi?id=91520)
Votes for 'Wrap search' by default (11):
Nick Treleaven, John Levon, Blake Ross, Jesse Ruderman, NeilBecker, TGOS, Mike Stockman, Andrew Pimlott, Tom Schneider, realgrouchy, "search autowrap on by default" poster (anonymous)
Votes against 'Wrap search' by default (2):
timeless, FredEnrico Tröger was impartial, stating "I don't mind much, we can change the default."
Everything's up to you, but I do feel that this default would make search more friendly for new users.
I'm not sure such bug reports are really good source for stats since I'd think it's way more likely people that do like the pre-bug state didn't see the bug or mind commenting than people wanting the feature.
If we want "real" stats, maybe polling the Geany user ML would be the thing to do.
However I don't mind much either what's the default. If it's true that people tend to prefer wrap by default, why not -- and when Dimitar's patch will be applied it'll be easy to change.
Also, sorry to be all talk and no contribution yet... But I am currently working on a HAML lexer for Scintilla, as well as improvements to the TreeBrowser plugin.
Don't worry, it's not a problem. Giving patch is of course better, but requesting/discussing features is fine.
Regards, Colomban
Le 04/12/2011 14:44, Dimitar Zhekov a écrit :
On Sun, 04 Dec 2011 00:48:40 +0100 Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 03/12/2011 20:56, Dimitar Zhekov a écrit :
There is one, and only one thing, that is unquestionably better IMHO: separate [ ] "Always wrap search and hide the Find dialog" into [...]
Yep, this sounds sensible to me. It'd be better flexible and I can understand somebody was one and not the other. So yeah, go ahead :)
It turned out to be quite easy, because the two meanings are actualy used separately...
Great!
A few comments:
* I better see the new prefs under the [serach] group, with "pref_main_" prefix stripped;
* The GeanySearchPrefs struct change breaks the plugin ABI since it changes the offset of the "use_current_word" field that is in the API [1]. Since the prefs are not a whole anymore, just put one in place of "suppress_dialogs" and add the other somewhere after "use_current_word" (the only field in the API).
Apart these, the patch looks just fine and work good :)
Regards, Colomban
[1] Although I can't find any plugin using it, neither in code Geany nor in geany-plugins...
On Sun, 04 Dec 2011 19:22:55 +0100 Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 04/12/2011 14:44, Dimitar Zhekov a écrit :
It turned out to be quite easy, because the two meanings are actualy used separately...
Great!
A few comments:
- I better see the new prefs under the [serach] group, with
"pref_main_" prefix stripped;
Moved them just above "pref_search_current_file_dir" and removed "main_". Not sure about the "pref_search_" though. All [search] settings have a dialog prefix or infix, and "pref_search_" looks to me like "Preferences dialog, Search section". If that's not the case, please rename them as you see fit.
The compatibility code became a bit worse.
- The GeanySearchPrefs struct change breaks the plugin ABI since it
changes the offset of the "use_current_word" field that is in the API [1]. Since the prefs are not a whole anymore, just put one in place of "suppress_dialogs" and add the other somewhere after "use_current_word" (the only field in the API).
suppress_dialogs -> always_wrap, hide_find_dialog at end.
Le 05/12/2011 20:27, Dimitar Zhekov a écrit :
On Sun, 04 Dec 2011 19:22:55 +0100 Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 04/12/2011 14:44, Dimitar Zhekov a écrit :
It turned out to be quite easy, because the two meanings are actualy used separately...
Great!
A few comments:
- I better see the new prefs under the [serach] group, with
"pref_main_" prefix stripped;
Moved them just above "pref_search_current_file_dir" and removed "main_". Not sure about the "pref_search_" though. All [search] settings have a dialog prefix or infix, and "pref_search_" looks to me like "Preferences dialog, Search section". If that's not the case, please rename them as you see fit.
Well, I see many prefs are prefixed with pref_*_, so it's fine. And it's not like it's that important either.
The compatibility code became a bit worse.
- The GeanySearchPrefs struct change breaks the plugin ABI since it
changes the offset of the "use_current_word" field that is in the API [1]. Since the prefs are not a whole anymore, just put one in place of "suppress_dialogs" and add the other somewhere after "use_current_word" (the only field in the API).
suppress_dialogs -> always_wrap, hide_find_dialog at end.
Applied, thanks!
Cheers, Colomban
On 12/05/2011 01:27 PM, Colomban Wendling wrote:
Applied, thanks!
Ouch! I wonder how many hours it will take me to convert the old Glade 2 file to GtkBuilder *again*.
I say we either delete the gtkbuilder branch or merge it into master. It's basically working fine for along time and I don't think anyone is testing it since it's not in master.
Cheers, Matthew Brush
On Tue, Dec 6, 2011 at 12:18 PM, Matthew Brush mbrush@codebrainz.ca wrote:
On 12/05/2011 01:27 PM, Colomban Wendling wrote:
Applied, thanks!
Ouch! I wonder how many hours it will take me to convert the old Glade 2 file to GtkBuilder *again*.
I say we either delete the gtkbuilder branch or merge it into master. It's basically working fine for along time and I don't think anyone is testing it since it's not in master.
I agree, why hasn't it been committed already?
If no one has a reasonable objection by the end of the week I suggest you commit it Matthew.
If someone then has a real objection it can always be reverted, thats what Git is for.
Cheers Lex
Cheers, Matthew Brush _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 12/05/2011 05:52 PM, Lex Trotman wrote:
On Tue, Dec 6, 2011 at 12:18 PM, Matthew Brushmbrush@codebrainz.ca wrote:
On 12/05/2011 01:27 PM, Colomban Wendling wrote:
Applied, thanks!
Ouch! I wonder how many hours it will take me to convert the old Glade 2 file to GtkBuilder *again*.
I say we either delete the gtkbuilder branch or merge it into master. It's basically working fine for along time and I don't think anyone is testing it since it's not in master.
I agree, why hasn't it been committed already?
Because only a few people have tested it and we don't have a `devel` branch for "unstable" code :)
If no one has a reasonable objection by the end of the week I suggest you commit it Matthew.
I'll have to free up some time to reconvert the Glade 2 file again (biggest part of the job). It might actually take me less time (and agony) to revert this search patch and manually re-apply it ontop of the gtkbuilder branch before merging it into master. There was a lot of little tedious things in converting the Glade 2 file to GtkBuilder and I'd really rather not go through that again (it took weeks of testing to catch all the little subtle bugs and changes).
Cheers, Matthew Brush
Le 06/12/2011 03:02, Matthew Brush a écrit :
On 12/05/2011 05:52 PM, Lex Trotman wrote:
On Tue, Dec 6, 2011 at 12:18 PM, Matthew Brushmbrush@codebrainz.ca wrote:
On 12/05/2011 01:27 PM, Colomban Wendling wrote:
Applied, thanks!
Ouch! I wonder how many hours it will take me to convert the old Glade 2 file to GtkBuilder *again*.
I say we either delete the gtkbuilder branch or merge it into master. It's basically working fine for along time and I don't think anyone is testing it since it's not in master.
I agree, why hasn't it been committed already?
Because only a few people have tested it and we don't have a `devel` branch for "unstable" code :)
It'd need people to try the "devel" branch too ;)
Well. I haven't tried the branch that much either -- only tried it once actually I think. My bad.
However I agree that it should be merged into master. It'd get more testing, we want this change to happen and currently we "fear" changing the UI file, which is not good for development (actually it didn't wanted to change the UI 'til that patch, but still). And IIUC you use the branch, so there shouldn't be *too* annoying bugs.
So +1 for you to merge it to master, and we'll handle any problem if there are some.
Regards, Colomban
On 12/06/2011 11:34 AM, Colomban Wendling wrote:
Le 06/12/2011 03:02, Matthew Brush a écrit :
On 12/05/2011 05:52 PM, Lex Trotman wrote:
On Tue, Dec 6, 2011 at 12:18 PM, Matthew Brushmbrush@codebrainz.ca wrote:
On 12/05/2011 01:27 PM, Colomban Wendling wrote:
Applied, thanks!
Ouch! I wonder how many hours it will take me to convert the old Glade 2 file to GtkBuilder *again*.
I say we either delete the gtkbuilder branch or merge it into master. It's basically working fine for along time and I don't think anyone is testing it since it's not in master.
I agree, why hasn't it been committed already?
Because only a few people have tested it and we don't have a `devel` branch for "unstable" code :)
It'd need people to try the "devel" branch too ;)
Good point :)
Well. I haven't tried the branch that much either -- only tried it once actually I think. My bad.
It's hard to use it consistently for day-to-day use since we're always testing stuff from master and whatnot, no worries.
However I agree that it should be merged into master. It'd get more testing, we want this change to happen and currently we "fear" changing the UI file, which is not good for development (actually it didn't wanted to change the UI 'til that patch, but still). And IIUC you use the branch, so there shouldn't be *too* annoying bugs.
The main thing I can notice is some warnings on the console (I think about some shared menu items), but I couldn't notice any missing functionality and I couldn't figure where the messages were coming from since there's no line number, just process ID.
So +1 for you to merge it to master, and we'll handle any problem if there are some.
Will do this weekend then. I'm certain there will be some bugs but probably mostly minor and it will help having better programmers than me working on it too :)
Cheers, Matthew Brush
Le 07/12/2011 02:35, Matthew Brush a écrit :
On 12/06/2011 11:34 AM, Colomban Wendling wrote:
[...]
However I agree that it should be merged into master. It'd get more testing, we want this change to happen and currently we "fear" changing the UI file, which is not good for development (actually it didn't wanted to change the UI 'til that patch, but still). And IIUC you use the branch, so there shouldn't be *too* annoying bugs.
The main thing I can notice is some warnings on the console (I think about some shared menu items), but I couldn't notice any missing functionality and I couldn't figure where the messages were coming from since there's no line number, just process ID.
Run in a debugger with the G_DEBUG env var set to "fatal-warnings", so the program will abort and let you see where/when/how it happened.
Cheers, Colomban
On 12/07/2011 06:12 AM, Colomban Wendling wrote:
Le 07/12/2011 02:35, Matthew Brush a écrit :
On 12/06/2011 11:34 AM, Colomban Wendling wrote:
[...]
However I agree that it should be merged into master. It'd get more testing, we want this change to happen and currently we "fear" changing the UI file, which is not good for development (actually it didn't wanted to change the UI 'til that patch, but still). And IIUC you use the branch, so there shouldn't be *too* annoying bugs.
The main thing I can notice is some warnings on the console (I think about some shared menu items), but I couldn't notice any missing functionality and I couldn't figure where the messages were coming from since there's no line number, just process ID.
Run in a debugger with the G_DEBUG env var set to "fatal-warnings", so the program will abort and let you see where/when/how it happened.
Great tip, thanks!
Cheers, Matthew Brush
On 12/05/2011 05:18 PM, Matthew Brush wrote:
On 12/05/2011 01:27 PM, Colomban Wendling wrote:
Applied, thanks!
Ouch! I wonder how many hours it will take me to convert the old Glade 2 file to GtkBuilder *again*.
FWIW, it didn't actually take too long to update the gtkbuilder branch. Instead of re-converting the whole Glade 2 file I just manually added the changes to the new geany.glade using Glade 3, comparing the changes in the diff (since I don't have a patched Glade 2 running anymore) and then I added that in with the merge commit.
Cheers, Matthew Brush
Le 06/12/2011 06:08, Matthew Brush a écrit :
On 12/05/2011 05:18 PM, Matthew Brush wrote:
On 12/05/2011 01:27 PM, Colomban Wendling wrote:
Applied, thanks!
Ouch! I wonder how many hours it will take me to convert the old Glade 2 file to GtkBuilder *again*.
Yeah, I know, sorry. I tried to ping you the other day on IRC for that, but you seemed AFK, and decided that I/you could "easily" recreate the patch for this in the GtkBuilder format -- it would've need somebody do re-do the thing anyway at some point.
FWIW, it didn't actually take too long to update the gtkbuilder branch. Instead of re-converting the whole Glade 2 file I just manually added the changes to the new geany.glade using Glade 3, comparing the changes in the diff (since I don't have a patched Glade 2 running anymore) and then I added that in with the merge commit.
Great! :)
Cheers, Colomban