> 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.