Patches item #3400300, was opened at 2011-08-29 15:08 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3400300...

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: feature Status: Open Resolution: None Priority: 6 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: move cord drawing from pd to Tcl procs in pd-gui

Initial Comment: This patch replaces the raw Tcl code in the 'pd' process' C code with two Tcl procs in pdtk_canvas: draw_signal_cord and draw_message_cord. This allows for customization of the cords from GUI plugins and Pd patches. This also is a step in the direction of making the 'pd' --> 'pd-gui' communications Pd messages rather than Tcl code.

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

Comment By: Hans-Christoph Steiner (eighthave)

Date: 2011-08-31 12:57

Message: (oops that was me not logged in)

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

Comment By: Nobody/Anonymous (nobody) Date: 2011-08-31 12:57

Message: You just answered your question :) The line width is one difference between signal and message cords. Another would be to have different colors, different line ending treatments, different patterns, etc. Some people might want to make Pd look like Max/MSP for example, and that has weird stripey cords. Another reason to have the signal/message conditional in C is speed. It'll execute much faster there.

And really, I don't see the difference between adding a proc and adding another block in a if/then/else statement. Both are very straightforward and easy.

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

Comment By: Jonathan Wilkes (jancsika1) Date: 2011-08-31 01:59

Message: Oops, I guess "drawing instructions" is an ambiguous term. I just mean the coordinates: startx/y and endx/y. All the other options could be done with a conditional.

BTW-- any reason you are hardcoding a width of "2" in that proc? Shouldn't it be something like -width $::signalcordwidth, with ::signalcordwidth being defined in pd-gui.tcl? (Could also use the options database but that's probably overkill.)

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

Comment By: Jonathan Wilkes (jancsika1) Date: 2011-08-30 23:23

Message: I think you just need one proc with an arg corresponding to control/signal. All customization can be done elsewhere by referring to the tags. I can't think of any divergences between messagecord (controlcord?) and signalcord that would require different initial drawing instructions; all future features I can think of-- segmented cords or new cord selection/deletion/edition-- would be handled identically for both cases, no? If you disagree, could you give an example of a way in which a signalcord would ever require different drawing instructions than a controlwire?

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

Comment By: Hans-Christoph Steiner (eighthave) Date: 2011-08-30 12:36

Message: I think having separate procs/messages for each connection type makes it easier to customize. And its just as easy to add a proc for any new connection type as it is to add a block to a switch or something like that. Given that no new connection types have been added to Pd since its inception, I don't think its a high priority concern.

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

Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-30 03:09

Message: i haven't had a look yet, but wouldn't it be better to use a single tcl-proc "connect" (or "draw_cords") and specify the type of connection as an argument? this way it can be more easily expanded to other connection types.

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

You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3400300...