1. The tooltip of the global options in fluid describes the purpose of OPTION_VISIBLE_FOCUS better than the actual docs:

OPTION_VISIBLE_FOCUS

If visible focus is switched on, 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.

Note the last part "... and keyboard navigation is disabled".

The docs should make this clear and I'll try to do this (that's why I added the label "documentation").

2. See 1.

3. The effect is correct as far as it does visually indicate the focus (when the widget has the focus) and that it enables keyboard navigation with TAB, i.e. widgets that have VISIBLE_FOCUS disabled are skipped when you press TAB.

Run the modified input prog, put focus and click mouse as above : the clicked button has no dotted line but the focus stays in the top text field ...

In my version the clicked button has the dotted line which is another issue and I found a fix for it. I'm attaching my current patch which is still work in progress.
issue-366_focus.diff

This patch includes the suggested fix in Fl::focus() which is not yet fully tested. I also had to make unsigned int visible_focus() const which is another fix (this should have been done anyway).

Do we want Fl_Widget::visible_focus(int) to have both these effects?

Yes, definitely.

Do we need something that prevents focus being transmitted to a widget, knowing that
the widget's handle method returning 0 to the FL_FOCUS event does that already ?

Yes. The difference is like having to derive a class or to use a callback, in this case you'd have to derive a class and implement the handle() method to reject FL_FOCUS events. It's much simpler from a programmer's point of view to call Fl_Widget::visible_focus(0) in cases when this is needed or wanted.

The docs should also clearly state that you can still set the focus to the widget if you disable VISIBLE_FOCUS by calling for instance Fl::focus(this) or similar. This is not possible in current FLTK but works with my patch.

Yet another test case: set visible_focus(0) on one of the input fields. You'll notice that this field will be skipped by tab navigation. However, you can't click into the field to set the focus and start typing in the unmodified FLTK lib. My patch fixes this as well. The same applies to Fl_Text_Display and its derived class Fl_Simple_Terminal which was the root cause of issue #365 and led me to open this one (#366).

I'm still investigating but test results with my posted patch would be very much appreciated. Does this patch have any unwanted side effects?

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.Message ID: <fltk/fltk/issues/366/1011324124@github.com>