Patches item #1552482, was opened at 2006-09-05 01:48 Message generated for change (Comment added) made by lukeiannini You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1552482...
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: bugfix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Luke Iannini (lukeiannini) Assigned to: Miller Puckette (millerpuckette) Summary: update to [cnv] help to document arguments
Initial Comment: The canvas object seems to take arguments happily enough - while I could not find this documented, I discovered what went where by trying "cnv a b c d e f g h..." and checking where they ended up in the properties. This worked, but while the arguments appear in the properties, they do not actually "show up" in the canvas until the property window is closed again.
I've attached a patch that demonstrates this behavior.
(I was hoping to build a "canvas generator" that would save me the trouble of opening property windows to set dimensions or a recieve symbol that could be used with Joao Miguel Pais's "gui-edit" abstraction. But the receive symbol does not start functioning until the props are opened, then closed.)
Also, the first 3 arguments do not seem to do anything (they'd logically control "selectable size" and the x and y dimensions of the canvas).
----------------------------------------------------------------------
Comment By: Luke Iannini (lukeiannini)
Date: 2007-11-19 09:11
Message: Logged In: YES user_id=1541432 Originator: YES
Sorry I never did this, here's the file. File Added: my_canvas-help.pd
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-06-14 08:20
Message: Logged In: YES user_id=27104 Originator: NO
this patch does not apply cleanly to anything that I tried. Please submit the original pd help patch rather than the diff/patch file. diffs don't really work with .pd files.
----------------------------------------------------------------------
Comment By: Luke Iannini (lukeiannini) Date: 2006-09-20 02:45
Message: Logged In: YES user_id=1541432
Hello Hans, Done : ). But I can't effect the bug>patch change.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave) Date: 2006-09-15 17:54
Message: Logged In: YES user_id=27104
It would be awesome then if you updated the help file and submitted that as a patch to the tracker. Then the rest of us can benefit from your explorations.
You can attach an updated help file to this tracker, then change it from a "Bug" to a "Patch".
----------------------------------------------------------------------
Comment By: Luke Iannini (lukeiannini) Date: 2006-09-05 03:12
Message: Logged In: YES user_id=1541432
Sorry about that, thanks!
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig) Date: 2006-09-05 03:03
Message: Logged In: YES user_id=564396
this is, because you are using wrong arguments and not because of a bug in [cnv]. attached is a working patch (which uses more arguments than the original one)
there are 4 possibilities to "reverse engineer" the arguments of an object: 1) read the help (won't help you with [cnv]) 2) read the pd-list (ask! chances are high that somebody already solved your problem) 3) read the patch (save a patch with the object as you would like it; open the patch with a text editor; look which arguments are used; understand what the arguments mean) 4) read the source
esp. #3 is a very simple and efficient and good way to discover the arguments of an object (the object usually knows best which arguments it needs)
----------------------------------------------------------------------
Comment By: Luke Iannini (lukeiannini) Date: 2006-09-05 01:50
Message: Logged In: YES user_id=1541432
This is on Pd-x-39.2t4 (OS X.4.7 PPC)
----------------------------------------------------------------------
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1552482...
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.
.hc
On Nov 19, 2007, at 11:11 AM, SourceForge.net wrote:
Patches item #1552482, was opened at 2006-09-05 01:48 Message generated for change (Comment added) made by lukeiannini You can respond by visiting: https://sourceforge.net/tracker/? func=detail&atid=478072&aid=1552482&group_id=55736
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: bugfix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Luke Iannini (lukeiannini) Assigned to: Miller Puckette (millerpuckette) Summary: update to [cnv] help to document arguments
Initial Comment: The canvas object seems to take arguments happily enough - while I could not find this documented, I discovered what went where by trying "cnv a b c d e f g h..." and checking where they ended up in the properties. This worked, but while the arguments appear in the properties, they do not actually "show up" in the canvas until the property window is closed again.
I've attached a patch that demonstrates this behavior.
(I was hoping to build a "canvas generator" that would save me the trouble of opening property windows to set dimensions or a recieve symbol that could be used with Joao Miguel Pais's "gui-edit" abstraction. But the receive symbol does not start functioning until the props are opened, then closed.)
Also, the first 3 arguments do not seem to do anything (they'd logically control "selectable size" and the x and y dimensions of the canvas).
Comment By: Luke Iannini (lukeiannini)
Date: 2007-11-19 09:11
Message: Logged In: YES user_id=1541432 Originator: YES
Sorry I never did this, here's the file. File Added: my_canvas-help.pd
Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-06-14 08:20
Message: Logged In: YES user_id=27104 Originator: NO
this patch does not apply cleanly to anything that I tried. Please submit the original pd help patch rather than the diff/patch file. diffs don't really work with .pd files.
Comment By: Luke Iannini (lukeiannini) Date: 2006-09-20 02:45
Message: Logged In: YES user_id=1541432
Hello Hans, Done : ). But I can't effect the bug>patch change.
Comment By: Hans-Christoph Steiner (eighthave) Date: 2006-09-15 17:54
Message: Logged In: YES user_id=27104
It would be awesome then if you updated the help file and submitted that as a patch to the tracker. Then the rest of us can benefit from your explorations.
You can attach an updated help file to this tracker, then change it from a "Bug" to a "Patch".
Comment By: Luke Iannini (lukeiannini) Date: 2006-09-05 03:12
Message: Logged In: YES user_id=1541432
Sorry about that, thanks!
Comment By: IOhannes m zmölnig (zmoelnig) Date: 2006-09-05 03:03
Message: Logged In: YES user_id=564396
this is, because you are using wrong arguments and not because of a bug in [cnv]. attached is a working patch (which uses more arguments than the original one)
there are 4 possibilities to "reverse engineer" the arguments of an object:
- read the help (won't help you with [cnv])
- read the pd-list (ask! chances are high that somebody
already solved your problem) 3) read the patch (save a patch with the object as you would like it; open the patch with a text editor; look which arguments are used; understand what the arguments mean) 4) read the source
esp. #3 is a very simple and efficient and good way to discover the arguments of an object (the object usually knows best which arguments it needs)
Comment By: Luke Iannini (lukeiannini) Date: 2006-09-05 01:50
Message: Logged In: YES user_id=1541432
This is on Pd-x-39.2t4 (OS X.4.7 PPC)
You can respond by visiting: https://sourceforge.net/tracker/? func=detail&atid=478072&aid=1552482&group_id=55736
------------------------------------------------------------------------ ----
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
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
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
-
Hans-Christoph Steiner -
Mathieu Bouchard -
SourceForge.net