Search widget

[holm.h...@gmail.com]

Hello,

I wonder if some of you have already written this:

I have a long list, and want to select one items. I would like to type in a text in a Fl_Input, when the text match a small number (~10) items I want the a window to pop up and the user can select one of the matching entries.
Easier for the user, and typos will be eliminated.

Do any of you have written such a widget earlier ?

Best regards
Håvard

[Albrecht Schlosser]

On 9/9/20 3:19 PM holm.h...@gmail.com wrote:
>
> I have a long list, and want to select one items. I would like to type
> in a text in a Fl_Input, when the text match a small number (~10) items
> I want the a window to pop up and the user can select one of the
> matching entries.
> Easier for the user, and typos will be eliminated.
>
> Do any of you have written such a widget earlier ?

I don't have such a widget, but I think that something like Fl_Choice
would be a good starting point to derive your own widget from. You could
create/edit/deactivate the choices depending on the input value. But
that's only a thought, maybe someone has a better idea or example.

[Greg Ercolano]

Fl_Choice_Input is what you're describing here, something I wrote
a while ago, and I think was the first widget from me added to FLTK.

OP might want a tighter integration though, like google's input field
and firefox's url input field where the menu auto-appears below the
entire input field, and doesn't grab focus so the user can still type
while the menu is posted.

So the menu probably needs to not be an actual menu, but just a drop down
text field that overdraws everything else. Might be a little tricky to do.

[holm.h...@gmail.com]

Hi,

I think your widget will work fine, I tested the code from https://www.fltk.org/doc-1.3/classFl__Input__Choice.html and find this promising.

Would it be possible to open the menu from the callbackfunction (choice_cb). I want the menu to open automatically when I have a good match.

Best regards
Håvard

[Greg Ercolano]

> Would it be possible to open the menu from the callbackfunction (choice_cb).
> I want the menu to open automatically when I have a good match.

Yes; Fl_Input_Choice is a conflation of Fl_Input and Fl_Menu_Button,
and the class exposes those two classes with the methods:

input() -- returns the Fl_Input instance
menubutton() -- returns the Fl_Menu_Button instance

..and the docs for Fl_Menu_Button indicate you can use popup() to post the menu, e.g.

_________________________________________________________________________________________
Fl_Menu_Button::popup():
https://www.fltk.org/doc-1.4/classFl__Menu__Button.html#a9c4b549c0fad2380153a64aa2d8e7d38


Act exactly as though the user clicked the button or typed the shortcut key.

The menu appears, it waits for the user to pick an item, and if they pick one
it sets value() and does the callback or sets changed() as described above.
The menu item is returned or NULL if the user dismisses the menu.
_________________________________________________________________________________________

Here's a little demo that automatically posts the menu after the app
has been running for 3 seconds:

#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/Fl_Input_Choice.H>
void timer_cb(void *data) {
Fl_Input_Choice *choice = (Fl_Input_Choice*)data;
choice->menubutton()->popup(); // post the menu
}
int main()
{
Fl_Window *window = new Fl_Window(320,200);
Fl_Input_Choice *choice = new Fl_Input_Choice(180,10,140,25, "Choice");
choice->add("Aaa");
choice->add("Bbb");
choice->add("Ccc");
window->end();
Fl::add_timeout(3.0, timer_cb, (void*)choice);
window->show();
return Fl::run();
}


Trouble is, as I predicted in my last post, when the menu posts, it steals keyboard
focus, which would be bad if triggered on keypresses from the user typing into the
input field.

So for instance when I run the above app, and start typing into the input field before
the 3 seconds expire, when the menu suddenly posts, I can no longer keep typing.

I imagine the popup menu must be doing a 'grab' or something, which can /maybe/ be
disabled, I'm not sure.. if it can't, that means this might be a tough route to go,
and a more fully custom widget might have to be crafted.

[Greg Ercolano]

On 2020-09-09 11:09, Greg Ercolano wrote:
> Trouble is, as I predicted in my last post, when the menu posts, it steals keyboard
> focus, which would be bad if triggered on keypresses from the user typing into the
> input field.
>
> So for instance when I run the above app, and start typing into the input field before
> the 3 seconds expire, when the menu suddenly posts, I can no longer keep typing.

You can maybe avoid that by taking a copy of the Fl_Input_Choice code, and making
your own derived class for the Fl_Menu_Button so that you can implement your own
handle() method that throws the typing events back to the Fl_Input widget.

You /probably/ want the menu to handle /some/ of the keyboard events, like
up/down arrow keys to allow the user to navigate the menu, and trap the
Enter key if the user has one of the items highlighted so it 'picks' that
item and fills in the Fl_Input field.

Also would have to take into account the effects of a window manager that
might be "focus follows mouse", where keyboard focus goes to the widget
under the mouse, where ever that may be. So be sure to redirect focus()
when the popup appears, to make sure it's where you want it to be.

[holm.h...@gmail.com]

Thanks for the code and the suggestions.  I will experience with the code and see if I can get it to work out.

Btw. another question. Would it be possible to activate the callback of a Fl_Button due to the "roller-mouse-button" ?

Would be most convenient in my application !

Best regards

[Greg Ercolano]

On 2020-09-09 11:49, holm.h...@gmail.com wrote:
> Thanks for the code and the suggestions.  I will experience with the code and see if I can get it to work out.
>
> Btw. another question. Would it be possible to activate the callback of a Fl_Button due to the "roller-mouse-button" ?

Hmm, doesn't it already do that?

If I run the 'test/buttons' application and click the middle mouse
(roller mouse button) on the button, it 'clicks'.

Maybe I'm missing something about your question though.

[Paul Hahn]

For my needs, I once crafted a combination of an Fl_Input and an Fl_Table (not actually placed together within a widget wrapper though). The user types in the input widget and at each keystroke (which includes the possibility of "wildcard" chars like '*', or even a backspace to remove a previous character) a filter operation on the table rows is performed. The filter operation is applied to a particular column that the user has previously designated, with the condition that the values in that column are already sorted (up or down). This is not an enterable table (all cells have fixed content), and focus remains in the input widget while typing is happening. At any time, the user can use the mouse to select one or more of the filtered rows as presented in the table. Of course, that does move focus from the input widget.

Perhaps counter-intuitive, but this combination has surprisingly good performance on my Linux platform, even with many thousands of rows in the table! Undoubtedly this is because the filtering is applied to sorted column data. There is virtually no delay after a character is typed into the input widget and the filter-selected rows are (re)displayed in the table.

 

[Ian MacArthur]

On 9 Sep 2020, at 19:56, Greg Ercolano wrote:

Hmm, my guess would be that Håvard wants to make the button respond to the scroll wheel motion, rather than the click?

That being the case, it’s pretty easy to subclass the button and catch the FL_MOUSEWHEEL events in the handle and do something suitable with them...

Or, if it is the click, then the handle would be for FL_MIDDLE_MOUSE.

Or maybe that’s not it at all?

[holm.h...@gmail.com]

Thanks Ian, Catching the GLMOUSEWHEEL work like a charm.

Best regards

[holm.h...@gmail.com]

Hi pdh...@compintensehpc.com,

Your approach with a combination of an Fl_Input and an Fl_Table also seems interesting. Do you have the code posted somewhere ?

Best regards
Håvard

[Paul Hahn]

On Wednesday, September 9, 2020 at 3:07:23 PM UTC-5 holm.h...@gmail.com wrote:

Hi pdh...@compintensehpc.com,

Your approach with a combination of an Fl_Input and an Fl_Table also seems interesting. Do you have the code posted somewhere ?

I am sorry Håvard, my code as currently written is proprietary. I am thinking to publish simplified versions of things I've done like this sometime in the future in a github repository. But no timeline yet.

But I was really trying to convey the concepts in what I did, in case it might be helpful to you in trying to do something similar (e.g., perhaps using a Fl_Browser instead of an Fl_Table?). It was straightforward. The greatest effort I expended was just implementing the filtering and table updating -- and that wasn't too bad actually, thanks to the nice way Fl_Table is implemented based on drawing cell contents via its draw_cell() method. My filter mechanism would ultimately select only a set of column data items and store their table row indexes in a std::set<int> variable. I would then access that variable to draw the corresponding full row contents within the draw_cell() method of my sub-classed Fl_Table. In other words, I needed to subclass Fl_Table, but not the Fl_Input widget. I just supplied a callback for the latter that drove the filtering as the user typed in characters.

[holm.h...@gmail.com]

Ok, thank you anyway.

I have posted quite a few problems here and almost always get good suggested solutions. I  do no always use the proposed solutions, but the process is always very positive for me - I appreciate someone to discuss issues with !

Best regards
Håvard