New Signaling system specifically for widgets

[rcoreilly]

Key features:

• simple closure with minimal args -- what is the min?

Alternative 1: One mega signal that blasts everything to everyone

type Signals int64 //enums:enum

const (
   Clicked Signals = iota
  ...
)

// apps can extend this for their own purposes

gi.NewButton(scene, "button").SetText("show").Connect(func(sig Signals) {
   if sig == Clicked {
      fmt.Println("clicked!")
   }
})

Alternative 2: Specific signals for each type of signal -- NO args

type Caller []func()

func (cl *Caller) Add(fun func()) {
    *cl = append(*cl, fun)
}

gi.NewButton(scene, "button").SetText("show").OnClicked.Add(func() {
      fmt.Println("clicked!")
})

Alternative 3: Better version of 1 with signal put up front

type Signals int64 //enums:enum

const (
   Clicked Signals = iota
  ...
)

// apps can extend this for their own purposes

type Caller map[Signal][]func()

gi.NewButton(scene, "button").SetText("show").Connect(Clicked, func() {
      fmt.Println("clicked!")
})

Alternative 4: Type safe direct methods (Revision of 2)

// generic manager

type Signals0 []func  // same as Caller above

type Signals1[T any] []func(T)

// has Add and Signal methods per obvious

type TextField struct {
    ...
   OnClicks Signals0
   OnKeyPresses Signals1[key.Key]
}

func (tf *TextField) OnClick(fun func()) { tf.OnClicks.Add(fun) }
// etc.

func (tf *TextField) Clicked() {  tf.OnClicks.Call() } // don't need a wrapper function for this..

gi.NewTextField(scene, "tf").OnClick(func() {
      fmt.Println("clicked!")
}).OnKeyPress(func(k key.Key) {
    fmt.Println("keypress", k)
}) 

[rcoreilly]

Problem: large space of event types avail on every widget

1. there are a large number of different event types that one might want to connect to, on any random widget https://developer.mozilla.org/en-US/docs/Web/Events

2. some widgets generate their own internal events based on raw input events -- in javascript, these turn into a small category of things like "changed" e.g., for value slider. but you also want the ability to "listen" to any raw event to synthesize your own custom behaviors.

3. the obvious impl is a map[eventtypes][]func() but that requires a homogenous func type -- can't get the key value or changed value or the mouse button etc. The obvious solution is to just pass an Event interface through the function, and you have to read out the info as needed. Indeed Kai confirms this is how JS works. map[eventtypes][]func(Event)

.On(gi.MouseButtonEvent, func(e gi.Event) {
   if e.Button() == mouse.Left && e.Action() == mouse.Press { // issue: these accessors are event specific....
       ...
   }
})

with specific signatures:

.OnMouseButton(func(e gi.MouseEvent) {
    // now have direct access to MouseEvent fields.. and methods..
})

4. to make it easier, we'd need many accessor methods on Event -- but many will not be relevant to various events -- can we come up with a complete Action and Button list that works for everything?? or enough of everything to be useful and not too gross. want to avoid having to cast into concrete type as much as possible..

5. another issue: PreventDefault and StopPropagation = e.SetHandled(). should be doable.

6. another example: https://pkg.go.dev/github.com/maxence-charriere/go-app/v9/pkg/app#HTMLButton

   • uses a scope arg to deal with robust re-setting vs. adding a new closure function. theirs is deep equals on any variadic arg.. can skip.. we could use the same idea as a key to have robust setting??
   • has a decent set of high-frequency "On.." specific methods (these could provide specific event types per method)
   • they use a code generator to generate signatures for everything -- makes it easier to have custom methods, but is kinda crazy...

[rcoreilly]

Note: using goosi/events.Listen as the map of event types.

Current GoGi system makes use of priorities to achieve overriding of default event handlers, and other such logic. Would be great if we can somehow use order of event registering as a way of doing that instead, "implicitly".

JavaScript has the Event.preventDefault() mechanism to accomplish this. Clearly something is needed.

We'll see how it goes..