should GUI-widgets know the canvas(es) they belong to?

[umlaeute]

when implementing #1765, i became fond of the idea, that "widgets" (the GUI-representation of an object), should be aware of the canvas they live on.

this allows for a basic workflow like:

1. create a new widget on a canvas (which associates the canvas with the widget)
2. interacting with the widget no longer requires a handle to the canvas

in practice this looks like this:

::pd::widget::create object 0x55d4482616a0 .x55d448258570.c 57 88
::pd::widget::config 0x55d4482616a0 -size 39 20 -text {float}
::pd::widget::destroy 0x55d4482616a0

i kind of like this, as it doesn't require us to send the canvas along with any command to the object.

there's also the vague idea that an object might appear on more than one canvases (think a numberbox that is displayed as GOP; opening the GOP-subpatch currently blanks the GOP-display on the parent; it would be nice if this was not the case.

what's wrong with this?

after working a bit with this, i'm not entirely sure anymore whether this is really worth it.

• it does add some state to the GUI
• it's still unproven whether we could eventually use this to show objects on nested GOP instances
• the current implementation adds a bit of boilerplate code to each "widgetbehavior", e.g.:

  proc myobject_select {obj state} {
    foreach cnv [::pd::widget::get_canvases $obj] {
      # show selection of $obj on this $cnv
    }
  }

alternatives?

we could of course just pass the cnv along when calling a widget's procs from Pd-core:

::pd::widget::destroy 0x55d4482616a0 .x55d448258570.c

urgh.

a somewhat nicer way is to still store the object->canvas association on the GUI, but handle this in the wrapper function (that forwards a generic call like ::pd::widget::select $obj 1 to the actual widget implementation myobject_select.

right now it goes like this:

proc ::pd::widget::select {obj state} {
  set fun [get_widget_proc select $obj]
  if { $fun eq {} } {set fun fallback_select }
  $fun $obj $state
}
proc myobject_select {obj state} {
  foreach cnv [::pd::widget::get_canvases $obj] {
      # show selection of $obj on this $cnv
    }
}

this could be modified to

proc ::pd::widget::select {obj state} {
  set fun [get_widget_proc select $obj]
  if { $fun eq {} } {set fun fallback_select }
    foreach cnv [::pd::widget::get_canvases $obj] {
        $fun $obj $cnv $state
    }
}
proc myobject_select {obj cnv state} {
      # show selection of $obj on this $cnv
}

(nevermind that this currently iterates over possibly multiple canvases)

this has the advantage that the Core->GUI communication need not carry the canvas along (and is thus more readable).
the drawback is, that there's some asymmetry between the Core->GUI call (somefun $obj $arg) and the actual implementation on the GUI (somerealfun $obj $cnv $arg)

thoughts?

[Ant1r]

How about using a current_canvas field?

proc ::pd::widget::select {obj state} {
  set fun [get_widget_proc select $obj]
  if { $fun eq {} } {set fun fallback_select }
    foreach cnv [::pd::widget::get_canvases $obj] {
      ::pd::widget::set_current_canvas $obj $cnv
      $fun $obj $state
    }
}
proc myobject_select {obj state} {
    set cnv [::pd::widget::get_current_canvas $obj]  
      # show selection of $obj on this $cnv
}

So the widget implementation doesn't depend on the fact we finally allow drawing on multiple canvases or not, and the widget interfaces don't need the canvas argument.

[umlaeute]

hmm. that looks almost as complicated as the current solution.

i start to think that providing an explicit cnv argument is probably not so bad: at least the widgets themselves do not need to be aware of any global data (even if it is fetched via a getter).

thanks for the input.