Add OnMenuNavigation to CompletionEntry

[mudler]

The function allows to bind when the user is navigating the menu entry.

I'm pretty sure this isn't aligned up with the code style, so I'm opening the PR to have feedback if this is something worth to add (I'd like to upstream this, as otherwise I'd be forced for some workarounds in https://github.com/mudler/golauncher ) !

Thank you!

[andydotxyz]

I'm not sure what this is for - can you expand on the use-case?
Naively I would think that the Entry.OnChanged would provide the change callback.

[mudler]

I'm not sure what this is for - can you expand on the use-case? Naively I would think that the Entry.OnChanged would provide the change callback.

I need to have an hook when the user is navigating the menu. At the moment, OnChanged is hooked on the Entry widget, which fires only when the user types something in the entry box.

My use case is the following: a user could hit Enter on the keyboard while typing something but without navigating the menu (with keyboard, or mouse, etc) - how can I tell when this happens? The PR adds a hook when the user actually navigates the menu, with the argument passed as the item ID.

In https://github.com/mudler/golauncher makes sense because the user might no need to navigate the menu at all, but still the intention behind it is to select the first matched entry

[andydotxyz]

If the OnChanged is not being called when a menu item is chosen then that sounds like a bug to me.

In https://github.com/mudler/golauncher makes sense because the user might no need to navigate the menu at all, but still the intention behind it is to select the first matched entry

Hmm, is OnSubmitted not the right hook to capture the enter press?

[mudler]

If the OnChanged is not being called when a menu item is chosen then that sounds like a bug to me.

I'm not totally sure if it's actually a bug. by looking at the widget , it composes several ones into one, and the hook I'm interested in this case is on the List widget created by it, but since the widget extends Entry OnChanged ends to be bind to that one (and not the list).

In https://github.com/mudler/golauncher makes sense because the user might no need to navigate the menu at all, but still the intention behind it is to select the first matched entry

Hmm, is OnSubmitted not the right hook to capture the enter press?

for the enter pass yes indeed that's what I end up using, but at that point I cannot query the status if the selection happened or not, so still I need an event to capture the menu selection, which is under the hood a list created by this widget.

[andydotxyz]

I'm not totally sure if it's actually a bug. by looking at the widget , it composes several ones into one, and the hook I'm interested in this case is on the List widget created by it, but since the widget extends Entry OnChanged ends to be bind to that one (and not the list).

Our widget APIs should be based on behaviour not implementation detail. Forget how it is built internally and base your thoughts on how it should function :)

for the enter pass yes indeed that's what I end up using, but at that point I cannot query the status if the selection happened or not, so still I need an event to capture the menu selection, which is under the hood a list created by this widget.

The thing I still don't understand is what is the difference of whether the item was in the list or was written by hand? SelectEntry does not care so to add this we really need to understand the use-case properly to get naming or workflow right.

[BabySid]

I have a similar use-case:

I hope to search and preview of my historical operation records through the completion entry.
When I type words in the entry, the popup menu show my records title.
When I use Key-Up/Down on the menu, another content show the title and detail of the record.
When I see the preview detail, I decide to use a historical record, I press enter to submit.

In order to understand the above scenario, I wrote a demo, and the screenshot is as follows:

Why I don't use Entry.OnChanged? Because when text in entry is changed, the result dont't meet my search need.
Why I Need the OnMenuNavigation? Because the menu's list is my search result.
Why I dont't use the OnSubmit? Because I need see the preview and decide whether the record is what i need.
Of course, I can type enter and use OnSubmit to show the detail, but it's very inconvenient because I need to keep on typing enter on the lists...

In addition, this component can actually have an OnSelected interface, so that when I press enter, the external component can get the corresponding event and directly carry out other operations, such as triggering a search. Now, I need to press enter on the popup menu and on the entry again, which is very inconvenient.

In the abstract, this component is not a simple entry, but an entry with the nature of list. Therefore, it needs to have the feature of list.

I don't know if I have described it clearly. If there is a problem, please reply to me~

[andydotxyz]

In addition, this component can actually have an OnSelected interface, so that when I press enter, the external component can get the corresponding event and directly carry out other operations, such as triggering a search. Now, I need to press enter on the popup menu and on the entry again, which is very inconvenient.

This is an interesting idea... we could mirror the OnSelected pattern elsewhere to avoid a whole new API?
It may have to be differentiated from possible text selection, but that shouldn't be too hard.

It avoids implying that this is navigation... or a menu ;).

[BabySid]

This is an interesting idea... we could mirror the OnSelected pattern elsewhere to avoid a whole new API? It may have to be differentiated from possible text selection, but that shouldn't be too hard.

It avoids implying that this is navigation... or a menu ;).

Sounds Good~

Currently, I have achieved a similar effect by extend CompletionEnty. I'm looking forward to FyneX can have a more elegant solution~

[andydotxyz]

I think this should have been "request changes" when the naming conflict was mentioned earlier.