The problem is for a subpatch that isn't vis'd:
[inlet]
|
[checkbutton]
|
[outlet]
Will give an error on "bang" because checkbutton_bang has:
sys_vgui("%s invoke\n", x->widget_id->s_name);
That could be solved by using a -variable option, but then that limits you
because the nonzero value cannot be changed.*
So yeah, the best solution is stored state in the struct so you can access it
in the c functions without caring about the vis state of the obj. Is that the
idea behind the options_binbuf?
* also note that checkbutton's default behavior is the opposite from tgl:
tgl: zero = off, nonzero = on
checkbutton: onvalue = on, everything else = off
>________________________________
>From: Hans-Christoph Steiner <[email protected]>
>To: Jonathan Wilkes <[email protected]>
>Cc: pd-dev List <[email protected]>
>Sent: Wednesday, August 17, 2011 7:24 PM
>Subject: Re: tkwidgets
>
>
>
>
>On Aug 17, 2011, at 6:23 PM, Jonathan Wilkes wrote:
>
>How does your private git branch differ from what's currently in svn?
>
>
>I pushed my git to github, my latest work is in the 'newentry' branch. I
>basically focused on the [entry] widget to see if I could get it going with
>this new approach.
>
>
>https://github.com/pd-projects/tkwidgets
>
>One thing I'd like to point out is that your tkwidgets suffer from the same
>problem tot/widget did -- by handling all the widget state in tcl you make it
>impossible to use your objects inside a subpatch/abstraction that doesn't have
>a visible canvas (because the widget no longer exists). I was considering
>create a "master" widget as a child of the main window and sync it to the
>widget drawn on the canvas, but that seems like a lot of trouble. Is there
>some other workaround?
>>
>
>
>That is true, but tkwidgets are all about using Tk widgets in Pd as easily as
>possible. If the Tk widget is not drawn to the screen, then the Tk widget is
>not involved. What is the problem in particular? You want to change its
>state while its not visible? I think the idea there is to have the state
>stored in the standard struct as a dump from the Tk widget. So when its not
>visible, store the state-changes, when it becomes visible, dump the state to
>the Tk widget.
>
>Another thing: to get "Pd-style" interaction, bind $canvas <<EditMode>> to a
>proc that sets -state to disabled for all tkwidgets in that $canvas when
>editmode == 1. That way you don't end up triggering the widget when you want
>to edit it.
>>
>
>
>Yeah, tkwidgets was mostly written about the same time as I starting the
>pd-gui-rewrite. As I rewrote a lot of pd-gui, I realized I should wait on
>tkwidgets since I could fix a lot of things in pd-gui first. The <<EditMode>>
>message is one example. tkwdigets is not complete yet, so this is not fully
>in there. I think the [entry] in github does this kind of stuff.
>
>
>.hc
>
>Hans-Christoph Steiner <[email protected]>
>>>To: Jonathan Wilkes <[email protected]>
>>>Cc: pd-dev List <[email protected]>
>>>Sent: Wednesday, August 17, 2011 2:54 PM
>>>Subject: Re: tkwidgets
>>>
>>>
>>>
>>>
>>>Hey Jonathan,
>>>
>>>
>>>I'm cc'ing pd-dev since this is a topic that could interest others and
>>>others could contribute to. I've started a private git branch of tkwidgets
>>>that I intent to push once I get somewhere with it. The idea is to try out
>>>a new idea for how GUI objects can work. Basically, I think I can make it
>>>so that Tcl handles more of the interaction with the user, minimizing on
>>>pd-gui <--> pd communications, and making it easier to write GUI objects.
>>>Its not trivial to do, but should be doable.
>>>
>>>
>>>.hc
>>>
>>>
>>>
>>>On Aug 17, 2011, at 12:26 PM, Jonathan Wilkes wrote:
>>>
>>>Never mind, I see it now inside canvas_vis... too bad canvas' "window"
>>>subcommand doesn't have something like pack's "-in" option...
>>>>
>>>>
>>>>But I guess I could make a toplevel checkbutton widget and just manually
>>>>clone it.
>>>>
>>>>
>>>>
>>>>-Jonathan
>>>>
>>>>
>>>>
>>>>
>>>>>________________________________
>>>>>From: Jonathan Wilkes <[email protected]>
>>>>>To: Hans- Christoph Steiner <[email protected]>
>>>>>Sent: Wednesday, August 17, 2011 3:14 AM
>>>>>Subject: tkwidgets
>>>>>
>>>>>
>>>>>Hi Hans,
>>>>> Do I have it right that your tkwidgets get destroyed when the
>>>>>containing patch is vis'd 0? If so, any hints on how this happens?
>>>>>
>>>>>
>>>>>Specifically, I'm playing around with [checkbutton], and even if I comment
>>>>>out everything in eraseme and checkbutton_free, and every single "destroy"
>>>>>subcommand, I still get a tcl error when sending a bang or float to a
>>>>>[checkbutton] that's in a subpatch with no window mapped:
>>>>>
>>>>>
>>>>>(Tcl) INVALID COMMAND NAME: invalid command name
>>>>>".x252a690.c.widget25272b0"
>>>>> while executing
>>>>>".x252a690.c.widget25272b0 cget -onvalue"
>>>>> ("uplevel" body line 2)
>>>>> invoked from within
>>>>>"uplevel #0 $cmd_from_pd"
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>>----------------------------------------------------------------------------
>>>
>>>
>>>
>>>Man has survived hitherto because he was too ignorant to know how to realize
>>>his wishes. Now that he can realize them, he must either change them, or
>>>perish. -William Carlos Williams
>>>
>>>
>>>
>>>
>
>
>
>
>----------------------------------------------------------------------------
>
>
>
>"We have nothing to fear from love and commitment." - New York Senator Diane
>Savino, trying to convince the NY Senate to pass a gay marriage bill
>
>
>_______________________________________________
Pd-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
