[PD] error on canvas while writing in object : tcl error: wrong # args: should be "pdtk_canvas_sendkey name state key iso shift"

[Ivica Ico Bukvic]

I tried in the past overloading things on tcl/tk side of things but that did
not work out all that well. In this case, however, it is not practical to do
so as the original implementation is inadequate to address the problem at
hand and maintaining bunch of workarounds is simply too time consuming to
push the project forward at a desired pace.

 

I think this is pretty much the reason why pd-l2ork exists. Pd-l2ork's
philosophy is that it will maintain backwards compatibility as long as that
does not require maintaining something broken/limited and whose workaround
would result in way more overhead than it would to address the third-party
libraries that rely on this. In this case it is AFAICT only Gridflow that
does this and it has not been updated in quite some time (please correct me
if I am wrong).

 

HTH

 

Best wishes,

 

Ico

 

From: Dan Wilcox [mailto:danomatika at gmail.com] 
Sent: Sunday, January 12, 2014 7:19 PM
To: Jonathan Wilkes; Ivica Ico Bukvic
Cc: pd-list at iem.at List
Subject: Re: [PD] error on canvas while writing in object : tcl error: wrong
# args: should be "pdtk_canvas_sendkey name state key iso shift"

 

It's not possible to overload the function? aka 1 that takes 5 args and
another that takes 7? From what I can tell, the usual style within the pd
core has been to add new args to the end so that backwards compatibility
isn't sacrificed. Then again, I don't know the details in this case ...

 

With libpd, so far, we've avoid trying to make any large, incompatible
changes to the core. Mainly, at least IMO, because we do not want to end up
diverging to the point to where we'll never be able to get said changes
upstream. At this point, I'd love to sit down with a bunch of you and work
out a proposed roadmap to separating gui & pd core so that libpd could
become the standard core between flavors. I haven't delved into the core
enough to know if that is a foolish idea, but it really seems like a great
idea to standardize some of the functionality ...

 

On Jan 12, 2014, at 5:55 PM, pd-list-request at iem.at wrote:





From: Jonathan Wilkes <jancsika at yahoo.com>

Subject: Re: [PD] error on canvas while writing in object : tcl error: wrong
# args: should be "pdtk_canvas_sendkey name state key iso shift"

Date: January 12, 2014 at 5:54:49 PM EST

To: pd-list at iem.at





On 01/12/2014 10:55 AM, Ivica Ico Bukvic wrote:

Hi,

This is because pd-l2ork has recently introduced a way of filtering
autorepeat keys so that [key], [keyup], and [keyname] objects only report
real key presses (as they should) while other forms of key input (e.g.
writing into an object box) still obey the autorepeat. This had to be done
in a way that breaks pdtk_canvas_send_key by adding an additional variable
and hence library like gridflow that hasn't kept up with pd-l2ork's updates
is no longer functioning as it should. Adapting this to pd-l2ork should not
take much of an effort--it is just a question of time and who will do it.


But notice the error tells the user that the proc expects five args, and not
seven args like your revision of pdtk_canvas_sendkey.  This is because matju
told Gridflow to steal the pdtk_canvas_sendkey proc and renamed it to
pdtk_canvas_sendqui (which is pretty funny in itself), and then it sends tcl
a brand new pdtk_canvas_sendkey proc with 5 args and code that presumably
has to do with unicode support.  I say that because you can find it in the
Gridflow source file named "unicorn.cxx" (which is also funny in itself).

So if you can figure out what it's doing, you can try to merging it into
Pd-l2ork or at least make it compatible with it.  But there are probably
several other places where matju drilled into Pd's walls from the outside,
and they probably conflict with Pd-l2ork's renovations.  (Probably the
widgetbehavior struct and comment struct conflict.)

-Jonathan

 

--------

Dan Wilcox

@danomatika

danomatika.com

robotcowboy.com

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140112/0f376ebf/attachment-0001.htm>