Fyne: Function callbacks on keypresses for Entry/Text/anything interactive

[asciifaceman]

It would be quite useful to have some custom callbacks on keypresses per entry type/box/instantiation. A cursory glance tells me his is used internally but not exposed to the implementer, but I may be wrong.

Ex. usage would be an enter key on an Entry box firing a button press, formatting/modifying text on change after a configurable delay (like autolinting but not meant to be specific to that use case), showing a wordcount per entry, etc.

[andydotxyz]

This is a complex topic and something that is being worked on right now.
"Key press" is a complex problem as we are aiming to support devices without keyboards etc - so the idea of a traditional key down needs to be abstracted.
Widgets can hook into "TypedRune" for a visible character and "TypedKey" for invisible keys (like return or backspace).

Widgets use these events to behave correctly and so things like Entry update the text accordingly. It is then up to widgets how to re-broadcast this information. Entry does this with OnChanged.

So the question really is - what do you want to achieve? We'd like to expose callbacks, but are aiming to provide higher level APIs where possible. For example "OnPaste" is more likely to be provided than "OnKeyDown" with Ctrl modifier + v.

The provided example could (i think) be done using the Entry.OnChanged but more complex examples will I am sure be thought of :).

There is a working document for key handling which may be relevant Input API

[andydotxyz]

we now have fyne.TypedKey(), fyne.TypedRune(), fyne.TypedShortcut() and desktop.KeyDown() and desktop.KeyUp() that widgets can use to get these events. the fyne.Canvas also exposes events for application fallback events.

Looking to update behaviour of widgets feels like a different topic. I think this can be closed - please respond if you think there are use-cases we have missed with some more information about what you would like to do.

[dkotik]

I currently do not see a way to capture an "Enter" KeyUp event on widget.Entry anywhere in the documentation. It is a fundamental functionality on many things, like for filter boxes or adding items. What am I missing?

[andydotxyz]

It is possible to listen to key events in widget code but Entry widget does not expose these direct events - by design.
A widget that wanted to extend entry could do so and override its behaviour on the enter key event, does this help?

Our design is that complex widgets would be created through extension rather than customisation.

[dkotik]

Makes sense. However, when I use basic composition, like below, the base widget stops updating (becomes completely frozen graphically, although the events seem to be firing):

func NewSearchField() *SearchField {
    search := widget.NewEntry()
    search.SetPlaceHolder(" Search")
    return &SearchField{search}
}

type SearchField struct {
    *widget.Entry
}

func (s *SearchField) KeyUp(k *fyne.KeyEvent) {
    switch k.Name {
    case fyne.KeyReturn:
        log.Fatal("keyUP", fmt.Sprint("%h", k.Name))
    }
    // s.Field.KeyUp(k)
    // widget.Refresh(s)
}

[andydotxyz]

Yes, sorry about this - until 1.2 which releases later this year there is another step you need to take - the CreateRenderer function must be overrode and return the renderer of the underlying widget. Apologies for this - we are working to make this process far simpler

[asciifaceman]

Just a note, things like the CreateRenderer function must be overrode and return the renderer of the underlying widget. can be impossible to grok sometimes if you don't know the stack like a lib dev

[dkotik]

Ok, I try to override like so, and no effect:

func (s *SearchField) CreateRenderer() fyne.WidgetRenderer {
    return s.Entry.CreateRenderer()
}

Also, is there any reason why widget.Button text align is protected from modifications? Can I contribute to expose it?

[andydotxyz]

Try ‘return widget.Renderer(s.Entry)’ instead

[andydotxyz]

Just a note, things like the CreateRenderer function must be overrode and return the renderer of the underlying widget. can be impossible to grok sometimes if you don't know the stack like a lib dev

I completely agree - we have not written much about custom widgets because it should be easier. Our approach is to fix the design instead of write extensive docs. In 1.2 this should all be moot.