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