FLTK handling of cursor keys doesn't make sense to me

[Edzard Egberts]

When using Fl_Tree I met a problem again, that I "patched out" some
years ago:

For Fl_Browsers and now Fl_Tree the handling of cursor keys doesn't make
sense to me - what is this moving frame good for? When I want to scroll
through items, it is not possible to use the cursor keys, because they
only move a frame and so I need to use the mouse to go from line to line
or use the combination "cursor key" + "space or enter", "cursor key" +
"space or enter", "cursor key" + "space or enter", and so on.

Regarding to Fl_Browser I changed this behaviour and got rid of moving
frame, but because of meeting this again, I now want to ask - does this
frame make any sense?

[Greg Ercolano]

On 04/05/18 02:51, Edzard Egberts wrote:
> When using Fl_Tree I met a problem again, that I "patched out" some
> years ago:

Short answer: sounds like you just want to set visible_focus(0)
to disable the "frame" (focus box) and keyboard navigation for
the widgets Fl_Browser and Fl_Tree.

So for instance, if you make this change to examples/tree-custom-sort.cxx:


Index: tree-custom-sort.cxx
===================================================================
--- tree-custom-sort.cxx (revision 12815)
+++ tree-custom-sort.cxx (working copy)
@@ -57,6 +57,7 @@
{
G_tree = new Fl_Tree(10, 10, win->w()-20, win->h()-60);
G_tree->showroot(0);
+ G_tree->visible_focus(0);

// Add 200 random numbers to the tree
char word[50];


..then the arrow keys can be used to inch the scrollbars along.

> For Fl_Browsers and now Fl_Tree the handling of cursor keys doesn't make
> sense to me - what is this moving frame good for?

That's keyboard navigation for the tree and browser you're describing.
It's a really common feature to navigate widgets without the mouse..?
For a list of the keyboard navigation keyboard bindings, see the
"KEYBOARD BINDINGS" section of the Fl_Tree docs.

You don't have to modify the code to turn this off; all FLTK widgets
inherit visible_focus() from Fl_Widget, which if set to zero, disables
keyboard navigation.. e.g. tree->visible_focus(0).

You can play with this in the test/tree program: under "Tree Globals",
un-check the "Visible focus?" and open the "500 Items" subtree, and test.

But keyboard nav is considered a desirable feature for all widgets,
which is why it defaults to being on.

If you really don't like the features of keyboard navigation at all,
you can turn it off globally throughout the application with:

Fl::option(Fl::OPTION_VISIBLE_FOCUS, 0);

..but note this disables tab navigation too.

[Greg Ercolano]

On 04/05/18 09:04, Greg Ercolano wrote:
> If you really don't like the features of keyboard navigation at all,
> you can turn it off globally throughout the application with:
>
> Fl::option(Fl::OPTION_VISIBLE_FOCUS, 0);

On that point: actually, I'm not so sure OPTION_VISIBLE_FOCUS is the global
equivalent for Fl_Widget::visible_focus(int).

The docs make it sound like it is:

---
OPTION_VISIBLE_FOCUS

If visible focus is switched on (default), FLTK will draw a dotted rectangle
inside the widget that will receive the next keystroke.

If switched off, no such indicator will be drawn and keyboard navigation is
disabled.
---

But after doing a few tests, it seems to NOT be equivalent.
I'll open a thread on fltk.coredev about that.

[Ian MacArthur]

It’s been a while, but ISTR you can use Fl::visible_focus(0); to globally inhibit the functionality?

[Greg Ercolano]

On 04/05/18 13:11, Ian MacArthur wrote:
> It’s been a while, but ISTR you can use Fl::visible_focus(0);
> to globally inhibit the functionality?

Sorta -- that affects focus delivery, but it is different
than Fl_Widget::visible_focus().

For instance, if I modify the examples/tree-custom-sort.cxx demo,
and put G_tree->visible_focus(0); after the Fl_Tree is created,
disabling the tree from handling arrow key navigation, then the
up/down arrows directly control the vertical scrollbar as it should.

But if I replace that with Fl::option(Fl::OPTION_VISIBLE_FOCUS,0);,
while there's no visible focus box, keyboard navigation of the tree
is still happening even though the focus box is invisible; if one
holds down the arrow key, imagine the focus box moving down the tree,
and when it reached the bottom, the tree suddenly begins scrolling
because the focus events are being handled by the tree, instead of
being ignored.

I need to look into this in Fl_Tree, as it sounds like a bug,
most likely due to my own personal misunderstanding of how to
properly manage focus in a widget that may have its own focus
navigation turned off, but child widget navigation turned on.
(Fl_Tree can also be a container for other FLTK widgets, where
each item can optionally have in it one or more fltk widgets)

[Edzard Egberts]

Greg Ercolano wrote:
> On 04/05/18 02:51, Edzard Egberts wrote:
>> When using Fl_Tree I met a problem again, that I "patched out" some
>> years ago:
>
> Short answer: sounds like you just want to set visible_focus(0)
> to disable the "frame" (focus box) and keyboard navigation for
> the widgets Fl_Browser and Fl_Tree.

No, I only want to disable the focus box, not the keyboard navigation.

My problem is, that keyboard navigation only moves the focus box, but
did not generate a callback. I want to go up and down with cursor keys,
like clicking to one line after the other with the mouse, so that I can
see directly the items that are connected to a browser line (user_data).

I understand, that this focus box can be used to "navigate" to a line
and then "activate" the line item by another key stroke (space). But
this is also easy to realise without focus box, just by not defining a
callback and evaluating the current line of the browser, when the
keystroke comes. But to realise the "direct cursor callback" I needed to
patch the handle()...

Thank you for the long answer and follows, but I think, you missed my point.