[PD-dev] [ pure-data-Patches-3400300 ] move cord drawing from pd to Tcl procs in pd-gui

SourceForge.net noreply at sourceforge.net
Wed Aug 31 18:57:46 CEST 2011


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&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: 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&group_id=55736



More information about the Pd-dev mailing list