[PD-dev] update to [cnv] help to document arguments

Hans-Christoph Steiner hans at eds.org
Tue Nov 27 00:48:07 CET 2007


I've got the text/entry stuff figured out, check out externals/ 
tkwidgets/text.c.  But [tkcanvas] is a new idea for me.  I think the  
tricky part would be managing the Tk tags in Pd space.  I think  
[tkcanvas] would just generate its Tk ID and use it internally.

So if people need to track the various elements that have been  
created on that canvas, they would have to use Tk tags and manage the  
tags themselves.  Or you can just create random stuff without tags...

.hc


On Nov 26, 2007, at 4:10 PM, Mathieu Bouchard wrote:

> On Mon, 26 Nov 2007, Hans-Christoph Steiner wrote:
>
>> Hmmm, upon thinking about this, this makes me think that the
>> tkwidgets library should include the tk canvas primitives like
>> "rectangle", "arc", "polygon", "line", etc.  The idea would be a
>> simple access to Tk drawing rather, which is a different mission than
>> Pd's graphical data structures. You can read more the Tk canvas here:
>> http://tcl.tk/man/tcl8.4/TkCmd/canvas.htm
>> I would love to have collaborators to develop tkwidgets library
>> completely, for example, the canvas.
>
> If you make a generic wrapper for all tk widget constructors, that  
> includes all the methods of the tk objects, then you will have  
> support for this automatically, by sending a "create line ..."  
> message to a [tkcanvas] pd object. Your tkwidgets library could  
> define a single anything-method for all its classes at once (just  
> like GridFlow does in its inter-language interface).
>
> Generally you should pass arguments from server to client  
> unchanged, but you may want to make a few exceptions, like if the  
> creation $1 doesn't start with a dot, your external would consider  
> it as a relative path and would prepend ".x12345678.c." only to  
> that argument. However, supporting relative paths in general would  
> require a lot more code, as various options of various commands  
> take only absolute widget paths, and the pattern isn't regular -  
> the constructor's $1 is just the most common case.
>
> Just make sure you create the tk object id in the server, so that  
> you don't have to pass it back to the server, which you shouldn't  
> do anyway because you want to support messages sent from [loadbang]  
> and stuff.
>
> The more difficult part is to get the values back and figuring out  
> what's the best way to handle them. Do you know how an object would  
> be used? For example, [tkentry], how does it return the symbol to  
> the server?
>
>   a) automatically, which is then automatically output at an outlet
>
>   b) automatically, which would then be output upon bang
>
>   c) manually, upon bang, and the symbol is output when it arrives  
> to the
>      server (which is implicitly like [delay])
>
>   d) manually, upon query-commands such as [$entry get 0 end] in  
> tk; then
>      a generic mechanism sends back from the client every return  
> value of
>      every command.
>
>   e) any combination of the above, as options offered to the user
>
> Note that a variant of (d) would have to be offered anyway for  
> handling error messages. Error messages have to round-trip through  
> the server so that "find again" works.
>
>  _ _ __ ___ _____ ________ _____________ _____________________ ...
> | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada



------------------------------------------------------------------------ 
----

Using ReBirth is like trying to play an 808 with a long stick.    - 
David Zicarelli






More information about the Pd-dev mailing list