2011/9/4 Jonathan Wilkes jancsika@yahoo.com
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Hans-Christoph Steiner hans@at.or.at Cc: pd-list pd-list@iem.at; João Pais jmmmpais@googlemail.com Sent: Saturday, September 3, 2011 6:31 PM Subject: Re: [PD] [PD-dev] tkwidgets
On Sat, 3 Sep 2011, Hans-Christoph Steiner wrote:
Here's a good example of what I mean: the drawing commands for obj,msg,
etc boxes should not be in 'pd'. 'pd' should tell 'pd-gui': "draw an object on this canvas, at this x,y with these inlets and outlets". "pd-gui" should also handle the mouse clicks, selection coloration, change of line style from dashed to solid,
etc.
So something like:
draw_object .x230ad0.c "osc~ 500" 10 500 inlet~ inlet outlet~
desiredata sends : change x9ad1038 x9acecc0 0 {#X obj 140 100 osc~ 500;} 2 1 1
this is not using sys_mgui(), though. I don't really remember why I
decided
to not use it. It's using the pd_upload() function in the server. The 4th argument is the line of the object as it would be written in a .pd file.
the 5th
and 6th arguments is the number of inlets and outlets, and the 7th
argument
means that the object is ok (no red dash). The first arg is the id of the object, the second arg is the id of the canvas, and the third arg is the
index
of the object (as used in #X connect).
This was for object updates, and was supposed to be replaced by something
more
efficient based on diffs. The other problem with uploading whole objects
was
that it didn't merge diffs, as has to happen when you move a slider that
is
currently receiving values or changing colour on its own, for example.
sys_mgui was meant for sending updates. You'd give an object id, then a selector, then an arg signature (like "fssfsffsf" to mean some combination of float and symbols, for example), then varargs. This
assumed that
the object id came first, as in most forms of object-oriented Tcl, and
unlike
plain procs.
the proc named «change» had to be a regular proc, because it's also responsible for creating the object if it does not exist, so that there isn't any special case for that, and then it couldn't be an instance method because the object might not exist yet.
If you spent the same amount of time working on DD as you do writing about how DD works, you could spend a lot less time writing about how DD works, and a lot more time working on DD. :)
-Jonathan
Hold on... When Matju talks about how DD works it's *almost* like backporting from DD to Pd, and in this sense it's historic. And because of the incompatible licenses, it might be the only way to port from DD to Pd. Pst...! :O)
Andras