When I want to change the case-sensitivity of a search, I don't like having to switch to the mouse and aim it toward the little checkbox. So I looked up why we disable tabbing to the other widgets (and found nothing). Then a little experimentation showed that triggering shortcuts causes widgets to get focus, which we don't want. With that answered, I tried letting the input do its own callbacks upon Enter or Shift-Enter, and letting everything accept focus. This isn't heavily tested, but I wanted to see how the idea goes over first...
On Tue, Dec 25, 2012 at 07:08:26PM +0000, corvid wrote:
When I want to change the case-sensitivity of a search, I don't like having to switch to the mouse and aim it toward the little checkbox.
So I looked up why we disable tabbing to the other widgets (and found nothing). Then a little experimentation showed that triggering shortcuts causes widgets to get focus, which we don't want.
With that answered, I tried letting the input do its own callbacks upon Enter or Shift-Enter, and letting everything accept focus.
This isn't heavily tested, but I wanted to see how the idea goes over first...
Beware, this is tricky. I remember having worked on this simplifying a lot the UI, by trying to avoid custom code/classes for each widget. IIRC, a relatively clean way to hook this shortcuts is to let the event get to the parent group, which in this case should focus its next child. -- Cheers Jorge.-
On Wed, Dec 26, 2012 at 05:24:27PM +0000, corvid wrote:
Jorge wrote:
IIRC, a relatively clean way to hook this shortcuts is to let the event get to the parent group, which in this case should focus its next child.
I'm not quite sure what you're saying here...
FLTK tries to deliver events in similar but different ways. AFAIR, for keystrokes, when a leaf widget is focused, it tries to deliver there first, and if not handled, then it goes upwards to its parent. If not handled all the way up, fltk tries "harder" to deliver it. Depending on the particular widget tree of the application and the internal algorithm used by fltk, is hard to predict exactly how this sequence goes. So a simple way to resolve the problem, is to code the handler in the common parent that encloses a closely related widget set (e.g. Findbar may do it in this case). e.g. let the event travel upwards to Findbar::handle(), do what's necessary there and return non zero (i.e. "handled"). (CustInput::handle() is a good example of this technique). -- Cheers Jorge.-
On Wed, Dec 26, 2012 at 11:29:50PM +0000, corvid wrote:
Here's what resulted, but it seems relatively inelegant: [snipped long patch]
It's much simpler. In this case you can let FLTK do the focus change among widgets: diff -r 20a26b8bb366 src/findbar.cc --- a/src/findbar.cc Wed Dec 26 23:31:48 2012 +0100 +++ b/src/findbar.cc Thu Dec 27 15:32:02 2012 -0300 @@ -158,7 +158,6 @@ Findbar::Findbar(int width, int height) check_btn = new Fl_Check_Button(x, border, 2*button_width, height, "Case-sensitive"); x += 2 * button_width + gap; - check_btn->clear_visible_focus(); add(check_btn); } and that's it, forward with Tab, back with Shift+Tab. Now, if there's a need for something more special, like letting Tab alone cycle around, adding this will do: @@ -179,6 +178,10 @@ int Findbar::handle(int event) if (event == FL_KEYBOARD && modifier == 0 && k == FL_Escape) { /* let the UI handle it */ return 0; + } else if (event == FL_KEYBOARD && modifier == 0 && k == FL_Tab) { + MSG("Findbar::handle FL_KEYBOARD Tab\n"); + (Fl::focus() == i) ? check_btn->take_focus() : i->take_focus(); + return 1; } return Fl_Group::handle(event); -- Cheers Jorge.-
Jorge wrote:
On Wed, Dec 26, 2012 at 11:29:50PM +0000, corvid wrote:
Here's what resulted, but it seems relatively inelegant: [snipped long patch]
It's much simpler. In this case you can let FLTK do the focus change among widgets:
diff -r 20a26b8bb366 src/findbar.cc --- a/src/findbar.cc Wed Dec 26 23:31:48 2012 +0100 +++ b/src/findbar.cc Thu Dec 27 15:32:02 2012 -0300 @@ -158,7 +158,6 @@ Findbar::Findbar(int width, int height) check_btn = new Fl_Check_Button(x, border, 2*button_width, height, "Case-sensitive"); x += 2 * button_width + gap; - check_btn->clear_visible_focus(); add(check_btn);
}
and that's it, forward with Tab, back with Shift+Tab.
Now, if there's a need for something more special, like letting Tab alone cycle around, adding this will do:
@@ -179,6 +178,10 @@ int Findbar::handle(int event) if (event == FL_KEYBOARD && modifier == 0 && k == FL_Escape) { /* let the UI handle it */ return 0; + } else if (event == FL_KEYBOARD && modifier == 0 && k == FL_Tab) { + MSG("Findbar::handle FL_KEYBOARD Tab\n"); + (Fl::focus() == i) ? check_btn->take_focus() : i->take_focus(); + return 1; }
return Fl_Group::handle(event);
I wanted to make the findbar as functional as one would customarily expect, though.
On Thu, Dec 27, 2012 at 08:38:24PM +0000, corvid wrote:
Jorge wrote:
On Wed, Dec 26, 2012 at 11:29:50PM +0000, corvid wrote:
Here's what resulted, but it seems relatively inelegant: [snipped long patch]
It's much simpler. In this case you can let FLTK do the focus change among widgets:
diff -r 20a26b8bb366 src/findbar.cc --- a/src/findbar.cc Wed Dec 26 23:31:48 2012 +0100 +++ b/src/findbar.cc Thu Dec 27 15:32:02 2012 -0300 @@ -158,7 +158,6 @@ Findbar::Findbar(int width, int height) check_btn = new Fl_Check_Button(x, border, 2*button_width, height, "Case-sensitive"); x += 2 * button_width + gap; - check_btn->clear_visible_focus(); add(check_btn);
}
and that's it, forward with Tab, back with Shift+Tab.
Now, if there's a need for something more special, like letting Tab alone cycle around, adding this will do:
@@ -179,6 +178,10 @@ int Findbar::handle(int event) if (event == FL_KEYBOARD && modifier == 0 && k == FL_Escape) { /* let the UI handle it */ return 0; + } else if (event == FL_KEYBOARD && modifier == 0 && k == FL_Tab) { + MSG("Findbar::handle FL_KEYBOARD Tab\n"); + (Fl::focus() == i) ? check_btn->take_focus() : i->take_focus(); + return 1; }
return Fl_Group::handle(event);
I wanted to make the findbar as functional as one would customarily expect, though.
Please elaborate. -- Cheers Jorge.-
Jorge wrote:
On Thu, Dec 27, 2012 at 08:38:24PM +0000, corvid wrote:
Jorge wrote:
On Wed, Dec 26, 2012 at 11:29:50PM +0000, corvid wrote:
Here's what resulted, but it seems relatively inelegant: [snipped long patch]
It's much simpler. In this case you can let FLTK do the focus change among widgets:
diff -r 20a26b8bb366 src/findbar.cc --- a/src/findbar.cc Wed Dec 26 23:31:48 2012 +0100 +++ b/src/findbar.cc Thu Dec 27 15:32:02 2012 -0300 @@ -158,7 +158,6 @@ Findbar::Findbar(int width, int height) check_btn = new Fl_Check_Button(x, border, 2*button_width, height, "Case-sensitive"); x += 2 * button_width + gap; - check_btn->clear_visible_focus(); add(check_btn);
}
and that's it, forward with Tab, back with Shift+Tab.
Now, if there's a need for something more special, like letting Tab alone cycle around, adding this will do:
@@ -179,6 +178,10 @@ int Findbar::handle(int event) if (event == FL_KEYBOARD && modifier == 0 && k == FL_Escape) { /* let the UI handle it */ return 0; + } else if (event == FL_KEYBOARD && modifier == 0 && k == FL_Tab) { + MSG("Findbar::handle FL_KEYBOARD Tab\n"); + (Fl::focus() == i) ? check_btn->take_focus() : i->take_focus(); + return 1; }
return Fl_Group::handle(event);
I wanted to make the findbar as functional as one would customarily expect, though.
Please elaborate.
Let's see, I wanted to be able to focus the input, the next and previous buttons, and the case-sensitive checkbox. I wanted to be able to activate the buttons and toggle the checkbox with either Space or Enter. I wanted to be able to Tab to each of them, shift-Tab to go back, and to have the tabbing wrap around. I thought a little about bringing the close button into the loop, but then I imagined it being easy to tab to by accident and inadvertently close the bar, especially given that it already has a key combination. I'm not quite sure, though.
participants (2)
-
corvid＠lavabit.com -
jcid＠dillo.org