Hi,
IIRC this is the first thread about this feature and I want to get it solved now ;-).
Basically, adding the code is not that hard. The only remaining question is how to make it accessable for the user. Nick suggested "Maybe just a keybinding to focus the search box that sets a reverse search flag, which is cleared when the search box loses focus would be enough." So, I think the keybinding would be the major way of using it. Anyway, I also think we need some kind of visible indication that the incremental search is in backwards mode.
IIRC Jeff suggested to change the background colour of the search box.
I could think of an additional button between the search box and the search button in the toolbar (even if this would bloat it a little more). This additional button would be a toggle button, which is in normal state (unpressed) if the usual forward incremental search is active, and it will be toggled(pressed) when the keybinding is pressed or the user pressed the button directly. So, you can quickly see in which mode the incremental search would work, the button indicates it. But it's just an idea.
Any opinions?
Regards, Enrico
On Wed, Mar 26, 2008 at 11:22 AM, Enrico Tröger enrico.troeger@uvena.de wrote:
IIRC Jeff suggested to change the background colour of the search box.
IIRC it was John ;-)
- Jeff
On Wed, 26 Mar 2008 11:40:46 -0500, "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
On Wed, Mar 26, 2008 at 11:22 AM, Enrico Tröger enrico.troeger@uvena.de wrote:
IIRC Jeff suggested to change the background colour of the search box.
IIRC it was John ;-)
Sorry :D.
Regards, Enrico
On Wed, 26 Mar 2008 17:22:45 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
Nick suggested "Maybe just a keybinding to focus the search box that sets a reverse search flag, which is cleared when the search box loses focus would be enough." So, I think the keybinding would be the major way of using it. Anyway, I also think we need some kind of visible indication that the incremental search is in backwards mode.
I'm not sure we need an indication if the backwards mode is reset once the focus leaves the search bar - the user can remember they pressed the search backward keybinding.
I could think of an additional button between the search box and the search button in the toolbar (even if this would bloat it a little more). This additional button would be a toggle button, which is in normal state (unpressed) if the usual forward incremental search is active, and it will be toggled(pressed) when the keybinding is pressed or the user pressed the button directly. So, you can quickly see in which mode the incremental search would work, the button indicates it. But it's just an idea.
I'm not sure a toggle button would be good. Perhaps having 2 buttons, like this: [ search text ] [ B ] [ F ] Where B is for search backwards and F forwards. This would be quicker to use than having to check the toggle button is set correctly before using the find button.
Another alternative is to use the existing find button to mean search backward when holding Shift, saving an extra button, but this has no visual indication or discoverability. Having an extra button would be best IMO.
Regards, Nick
On Wed, Mar 26, 2008 at 1:00 PM, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 26 Mar 2008 17:22:45 +0100
I'm not sure a toggle button would be good. Perhaps having 2 buttons, like this: [ search text ] [ B ] [ F ] Where B is for search backwards and F forwards. This would be quicker to use than having to check the toggle button is set correctly before using the find button.
'B' and 'F' might not translate well between languages. What I think looks good is either
[<] [search text] [>]
or else
[^] [search text] [v]
Also, I still think it would be good to visually indicate when you're in search backward mode. It would just make using the feature feel more intuitive, IMO. Maybe a hidden preference to color the field background a light dull yellow when in backward mode? (I suppose there could also be a corresponding hidden option to set that color value if you really wanted to be choosey.)
It would also be nice if the bubble help for the search field indicated that there is a search backward available.
---John
On Wed, 26 Mar 2008 13:18:34 -0400 "John Gabriele" jmg3000@gmail.com wrote:
On Wed, Mar 26, 2008 at 1:00 PM, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 26 Mar 2008 17:22:45 +0100
I'm not sure a toggle button would be good. Perhaps having 2 buttons, like this: [ search text ] [ B ] [ F ] Where B is for search backwards and F forwards. This would be quicker to use than having to check the toggle button is set correctly before using the find button.
'B' and 'F' might not translate well between languages. What I think looks good is either
[<] [search text] [>]or else
[^] [search text] [v]
Oops, I should have said that I didn't mean a literal B and F ;-) I was thinking we could use the same forward and back icons as the Find dialog uses, but then there is a conflict with the Navigate buttons.
Personally I don't like having the backwards button before the search text because the mouse has to move further when jumping between matches. I don't think it's necessary for the tab order to jump to the forward button first because you can just press enter in the search field anyway.
Also, I still think it would be good to visually indicate when you're in search backward mode. It would just make using the feature feel more intuitive, IMO. Maybe a hidden preference to color the field background a light dull yellow when in backward mode? (I suppose there could also be a corresponding hidden option to set that color value if you really wanted to be choosey.)
If we implement this it might as well be on by default IMO.
It would also be nice if the bubble help for the search field indicated that there is a search backward available.
Perhaps, but with the Backwards button this should be pretty clear.
Regards, Nick
On Wed, 26 Mar 2008 17:47:24 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 26 Mar 2008 13:18:34 -0400 "John Gabriele" jmg3000@gmail.com wrote:
On Wed, Mar 26, 2008 at 1:00 PM, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 26 Mar 2008 17:22:45 +0100
I'm not sure a toggle button would be good. Perhaps having 2 buttons, like this: [ search text ] [ B ] [ F ] Where B is for search backwards and F forwards. This would be quicker to use than having to check the toggle button is set correctly before using the find button.
'B' and 'F' might not translate well between languages. What I think looks good is either
[<] [search text] [>]or else
[^] [search text] [v]Oops, I should have said that I didn't mean a literal B and F ;-) I was thinking we could use the same forward and back icons as the Find dialog uses, but then there is a conflict with the Navigate buttons.
Personally I don't like having the backwards button before the search text because the mouse has to move further when jumping between matches. I don't think it's necessary for the tab order to jump to the forward button first because you can just press enter in the search field anyway.
I agree, if another button then after the search field.
Also, I still think it would be good to visually indicate when you're in search backward mode. It would just make using the feature feel more intuitive, IMO. Maybe a hidden preference to color the field background a light dull yellow when in backward mode? (I suppose there could also be a corresponding hidden option to set that color value if you really wanted to be choosey.)
If we implement this it might as well be on by default IMO.
And another >if we implement this<: then we should probably also make the "not found" colour (light red) configurable, maybe even in the pref dialog, not with a hidden pref.
So, what to choose? - The changing background colour of the text field doesn't take any new space on the toolbar but still requires for each backward search that the keybinding is pressed. - The additional button for backwards search is probably most intuitive and most easy to use, but eats some space. - Combine both? - Anything completely different? - Wait other three or four months to discuss again about it? (j/k)
It would also be nice if the bubble help for the search field indicated that there is a search backward available.
Perhaps, but with the Backwards button this should be pretty clear.
The tooltip(alias bubble help, a Windows word, or?) shouldn't be the problem at all, it's changed in less than a minute.
Regards, Enrico
On Fri, 28 Mar 2008 16:55:09 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
...
So, what to choose?
- The changing background colour of the text field doesn't take any
new space on the toolbar but still requires for each backward search that the keybinding is pressed.
- The additional button for backwards search is probably most
intuitive and most easy to use, but eats some space.
Well, we could make the search backwards button optional in Prefs.
- Combine both?
- Anything completely different?
- Wait other three or four months to discuss again about it? (j/k)
lol ;-)
It would also be nice if the bubble help for the search field indicated that there is a search backward available.
Perhaps, but with the Backwards button this should be pretty clear.
The tooltip(alias bubble help, a Windows word, or?) shouldn't be the problem at all, it's changed in less than a minute.
Yes, I see now that what John meant was to say that there is an *incremental* search backwards mode available by keybinding as well as the search backwards button.
Regards, Nick
On Fri, Mar 28, 2008 at 11:55 AM, Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 26 Mar 2008 17:47:24 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 26 Mar 2008 13:18:34 -0400 "John Gabriele" jmg3000@gmail.com wrote:
Also, I still think it would be good to visually indicate when you're in search backward mode. It would just make using the feature feel more intuitive, IMO. Maybe a hidden preference to color the field background a light dull yellow when in backward mode? (I suppose there could also be a corresponding hidden option to set that color value if you really wanted to be choosey.)
If we implement this it might as well be on by default IMO.
And another >if we implement this<: then we should probably also make the "not found" colour (light red) configurable, maybe even in the pref dialog, not with a hidden pref.
So, what to choose?
- The changing background colour of the text field doesn't take any
new space on the toolbar but still requires for each backward search that the keybinding is pressed.
- The additional button for backwards search is probably most intuitive
and most easy to use, but eats some space.
- Combine both?
I think that the search field background color should always change if you go to search backward mode (just like it always goes red for a failed search). Also, my guess is that users changing this color would be pretty rare.
Also, I think both buttons should always be present. One extra button doesn't take up a whole lot of room, and it also clearly indicates to the user that they can go in either direction. Also, as Nick said, next to eachother makes it easier to work them with the mouse (for those few users actually doing that ;) ).
On Fri, 28 Mar 2008 17:15:45 -0400, "John Gabriele" jmg3000@gmail.com wrote:
Also, I think both buttons should always be present. One extra button doesn't take up a whole lot of room, and it also clearly indicates to the user that they can go in either direction. Also, as Nick said, next to eachother makes it easier to work them with the mouse (for those few users actually doing that ;) ).
Ha, it doesn't matter how many users actually are those mouse shovers, I'm one of them...:D.
Regards, Enrico
On Fri, 28 Mar 2008 16:55:09 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
So, what to choose?
- The changing background colour of the text field doesn't take any
new space on the toolbar but still requires for each backward search that the keybinding is pressed.
- The additional button for backwards search is probably most
intuitive and most easy to use, but eats some space.
- Combine both?
- Anything completely different?
Really the main thing is the keybinding.
I think the issues are: 1. how to indicate backwards mode 2. how to save space 3. how to quickly search in the opposite direction
Personally I'm not keen on changing the background colour - it would serve its purpose, but there's not really any logic to it - why should backwards mode be a certain colour?
I think I made things more complicated by suggesting another button for searching backwards - perhaps we should just have the one button. Then in backwards mode, instead of the stock find icon, we can show the stock up icon. That way we wouldn't need to change the colour, and we save space.
The remaining thing for functionality could be if shift is held when enter is pressed from the search bar, or when clicking the find button, then reverse the search direction, just for that action.
Thoughts?
Regards, Nick
On Mon, 31 Mar 2008 16:00:07 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 28 Mar 2008 16:55:09 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
So, what to choose?
- The changing background colour of the text field doesn't take any
new space on the toolbar but still requires for each backward search that the keybinding is pressed.
- The additional button for backwards search is probably most
intuitive and most easy to use, but eats some space.
- Combine both?
- Anything completely different?
Really the main thing is the keybinding.
I think the issues are:
- how to indicate backwards mode
- how to save space
- how to quickly search in the opposite direction
Personally I'm not keen on changing the background colour - it would serve its purpose, but there's not really any logic to it - why should backwards mode be a certain colour?
I think I made things more complicated by suggesting another button for searching backwards - perhaps we should just have the one button. Then in backwards mode, instead of the stock find icon, we can show the stock up icon. That way we wouldn't need to change the colour, and we save space.
The remaining thing for functionality could be if shift is held when enter is pressed from the search bar, or when clicking the find button, then reverse the search direction, just for that action.
I'd agree with the above and want to start implementing it soon. Any objections? John are you fine with Nick's suggestion?
Regards, Enrico
On Mon, Mar 31, 2008 at 2:47 PM, Enrico Tröger enrico.troeger@uvena.de wrote:
On Mon, 31 Mar 2008 16:00:07 +0100, Nick Treleaven
nick.treleaven@btinternet.com wrote:
On Fri, 28 Mar 2008 16:55:09 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
So, what to choose?
- The changing background colour of the text field doesn't take any
new space on the toolbar but still requires for each backward search that the keybinding is pressed.
- The additional button for backwards search is probably most
intuitive and most easy to use, but eats some space.
- Combine both?
- Anything completely different?
Really the main thing is the keybinding.
I think the issues are:
- how to indicate backwards mode
- how to save space
- how to quickly search in the opposite direction
Personally I'm not keen on changing the background colour - it would serve its purpose, but there's not really any logic to it - why should backwards mode be a certain colour?
I think I made things more complicated by suggesting another button for searching backwards - perhaps we should just have the one button. Then in backwards mode, instead of the stock find icon, we can show the stock up icon. That way we wouldn't need to change the colour, and we save space.
The remaining thing for functionality could be if shift is held when enter is pressed from the search bar, or when clicking the find button, then reverse the search direction, just for that action.
I'd agree with the above and want to start implementing it soon. Any objections? John are you fine with Nick's suggestion?
I just a very brief comment on this:
If I understand Nick's comment about "the main thing is the keybinding", then I agree. Mouse users will click in the search field and click the corresponding search button. If you add a 2nd button, you automatically give the user more functionality practically for free. So I think the 2 adjacent buttons are a good idea (and I think from your other recent reply that you also like the idea of 2 buttons).
Mouse users may not even ever enter the search field in backward mode, and so may not ever know whether or not the search field's background color changes to anything besides red. However, when keyboard users find out that they can enter the field in a "search backward mode", it will look like a bug if there's no indication that widget bahaves differently but doesn't *look* different. With GUI's, if a widget behaviour changes, I think it should *look* like it has changed. If you don't like seeing the color change, you could always set its color to that of the default search field background. ;)
The only remaining part is integrating this GUI behaviour with some really usable keybindings for keyboard-only users.
I still think Nick's original idea of a special keybinding to enter the search field with search direction reversed is an excellent idea. Same goes for having it revert to regular search direction when you leave the search field. Some confusion that arises from this is:
1. When in search backward mode, do the buttons reverse their meanings? and 2. When in search backward mode, should Ctrl-G take you *forward* through the page or back? (Shift-Ctrl-G will take you the opposite direction.)
I won't comment on #1. Because if I did, and if you were changing the search field background color when in search backward mode, and if I said that the buttons should reverse their normal behaviour (though the button icon graphics would remain the same), you'd think I was nuts. So I won't even suggest it.
Regarding #2, I'm a bit of a crank. I've never liked using the Shift modifier to make a Ctrl-key action do its *reverse* (or compliment). Geany typically uses the Shift modifier to *augment* whatever the given Ctrl-key keybinding does. And Geany usually uses 2 separate keys for commonly-used complementary actions. Ctrl-G and Shift-Ctrl-G is about the only exception to that general rule, and to me it sticks out like a sore thumb. Yes, I realize it's pretty common GUI usage, but I don't think that makes it correct. :)
So, I'd say, if you were going to stay with the current way of doing things (that is, to keep using Ctrl-G and Shift-Ctrl-G as complementary keys), then when in search backward mode: Ctrl-G should probably take you *up* (backward on) the page, and Shift-Ctrl-G down (forward). If you like the sound of that, read no further. :)
........ That said, I still think it makes more sense to have separate keys for searching forward and searching backward. They're very commonly-used actions, they're complimentary, and they tend to each have their own button in GUIs, so it seems to make sense that they should each have their own separate keybinding key. If you're curious how Emacs does it, it does it like so:
* hitting Ctrl-s puts you in search forward mode * you type some letters and hit Ctrl-s again to hop down the page to the next search result. Keep tapping Ctrl-s to keep going to the next search result. * hitting Ctrl-r does the same, but for search backward. * hitting Return stops the search where you are (hitting the cancel keybinding brings you back to where the search began)
and it works very well. The icing on the cake is that you can switch from tapping one to tapping the other, and it simply takes you to search results in the opposite direction. Geany might attempt to do something similar:
* Ctrl-key1 puts you in the search field in forward mode. If the search field already has focus, more Ctrl-key1's move you to the next search result. * Ctrl-key2 puts you in the search field in backward mode. If the search field has focus, and is in backward mode, then repeated Ctrl-key2's moves you up the page to the next search search result. * In either case, a separate key binding brings focus back to the main editor pane.
That's probably the way I'd do it. It gives you 2 less keybindings to remember (it's 3 keys overall instead of 5), it frees you from having to do the slightly-clumsier Shift-Ctrl key combo, it's more consistent, and it removes confusion over which direction on the page a keybinding ([Shift-]Ctrl-G) will take you. Seems optimal to me.
---John
On Mon, Mar 31, 2008 at 10:25 PM, John Gabriele jmg3000@gmail.com wrote:
I just a very brief comment on this:
Whoops. So brief that I forgot a word: s{just}{just have}
I too have used the emacs C-s and C-r for incremental searching. Works great and has been around for a long time. Very handy and I like it. (Whether it is S and R or some other keys is immaterial, but I am used to the emacs keybindings) To exit the search, esc, or any arrow key should do it; anything but something you would search for (which leaves out the normal printable characters). So my 2 cents is that a third keybinding is probably not necessary.
chuck
John Gabriele wrote:
On Mon, Mar 31, 2008 at 10:25 PM, John Gabriele jmg3000@gmail.com wrote:
I just a very brief comment on this:
Whoops. So brief that I forgot a word: s{just}{just have} _______________________________________________ Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Tue, Apr 1, 2008 at 7:22 AM, chuck ctl@arrowtwins.com wrote:
I too have used the emacs C-s and C-r for incremental searching. Works great and has been around for a long time. Very handy and I like it. (Whether it is S and R or some other keys is immaterial, but I am used to the emacs keybindings) To exit the search, esc, or any arrow key should do it; anything but something you would search for (which leaves out the normal printable characters). So my 2 cents is that a third keybinding is probably not necessary.
chuck
I like this keybinding scene the Emacs guys talk about ;)
And regarding visual loopback, what about using one button and alternating the image on that button? I mean, the Find button combined with an arrow down or arrow up.
kilo
On Tue, Apr 1, 2008 at 2:44 AM, kilo kg_kilo@freemail.hu wrote:
And regarding visual loopback, what about using one button and alternating the image on that button? I mean, the Find button combined with an arrow down or arrow up.
If there were only one button, it would probably not be obvious to mouse users how to get it to do a search backward.
On Tue, 1 Apr 2008 10:21:07 -0400 "John Gabriele" jmg3000@gmail.com wrote:
On Tue, Apr 1, 2008 at 2:44 AM, kilo kg_kilo@freemail.hu wrote:
And regarding visual loopback, what about using one button and alternating the image on that button? I mean, the Find button combined with an arrow down or arrow up.
If there were only one button, it would probably not be obvious to mouse users how to get it to do a search backward.
Search->Find Previous ;-)
Regards, Nick
On Mon, 31 Mar 2008 22:25:55 -0400 "John Gabriele" jmg3000@gmail.com wrote:
However, when keyboard users find out that they can enter the field in a "search backward mode", it will look like a bug if there's no indication that widget bahaves differently but doesn't *look* different. With GUI's, if a widget behaviour changes, I think it should *look* like it has changed. If you don't like seeing the color change, you could always set its color to that of the default search field background. ;)
My point was just that there's no colour I associate with 'backwards', so it's not a particularly clear indication. Changing the button image to the up arrow does correspond with backwards.
...
- When in search backward mode, do the buttons reverse their
meanings? and 2. When in search backward mode, should Ctrl-G take you *forward* through the page or back? (Shift-Ctrl-G will take you the opposite direction.)
Well, I'm not keen on the button idea as I wrote before, but the behaviour would be like that, i.e. an ISB would make find next search up the document and find previous search down.
Regarding #2, I'm a bit of a crank. I've never liked using the Shift modifier to make a Ctrl-key action do its *reverse* (or compliment). Geany typically uses the Shift modifier to *augment* whatever the given Ctrl-key keybinding does. And Geany usually uses 2 separate keys for commonly-used complementary actions. Ctrl-G and Shift-Ctrl-G is about the only exception to that general rule, and to me it sticks out like a sore thumb. Yes, I realize it's pretty common GUI usage, but I don't think that makes it correct. :)
GTK users are used to it though. I don't think we'll change it - it's getting too complicated to move keybindings around, we've used pretty much all the available shortcuts.
Regards, Nick
On Wed, 26 Mar 2008 17:47:24 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 26 Mar 2008 13:18:34 -0400 "John Gabriele" jmg3000@gmail.com wrote:
or else
[^] [search text] [v]Oops, I should have said that I didn't mean a literal B and F ;-) I was thinking we could use the same forward and back icons as the Find dialog uses, but then there is a conflict with the Navigate buttons.
As John suggested in the 2nd example, we could use the stock up and down arrows - this would differentiate them from the navigation buttons.
Regards, Nick