On Mon, Mar 31, 2008 at 2:47 PM, Enrico Tröger firstname.lastname@example.org wrote:
On Mon, 31 Mar 2008 16:00:07 +0100, Nick Treleaven
On Fri, 28 Mar 2008 16:55:09 +0100 Enrico Tröger email@example.com 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.