On Mon, Mar 31, 2008 at 2:47 PM, Enrico Tröger <enrico.troeger(a)uvena.de> wrote:
On Mon, 31 Mar 2008 16:00:07 +0100, Nick Treleaven
<nick.treleaven(a)btinternet.com> wrote:
On Fri, 28 Mar 2008 16:55:09 +0100
Enrico Tröger <enrico.troeger(a)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.
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