I'd be careful exposing the tk canvas api from within Pd. It's a buggy interface, as evidenced by the off-by-one errors in the data-structure illustrations of Miller's book.
Hi Jonathan,
What do you mean by "exposing the tk canvas api" ? Is it about how I create GUI or about a specific object ? I made a lot of tests on Windows, Mac and Linux and it seems pretty stable. The fact is that I don't draw directly in the pd's canvas for many many reasons. You should have a look at the CICM wrapper.
Cheers
On 07/01/2015 06:42 AM, Pierre Guillot wrote:
I'd be careful exposing the tk canvas api from within Pd. It's a buggy interface, as evidenced by the off-by-one errors in the data-structure illustrations of Miller's book.
Hi Jonathan,
What do you mean by "exposing the tk canvas api" ? Is it about how I create GUI or about a specific object ? I made a lot of tests on Windows, Mac and Linux and it seems pretty stable. The fact is that I don't draw directly in the pd's canvas for many many reasons.
It looks like you have methods for some kind of 2d drawing surface. If those methods rely on Tk canvas subcommands to do the drawing (e.g., 'rect', 'polyline', etc.) then the user will encounter the kinds of bugs I mentioned.
You should have a look at the CICM wrapper.
Ok.
-Jonathan
Cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 07/01/2015 06:42 AM, Pierre Guillot wrote:
I'd be careful exposing the tk canvas api from within Pd. It's a buggy interface, as evidenced by the off-by-one errors in the data-structure illustrations of Miller's book.
Hi Jonathan,
[...]
The fact is that I don't draw directly in the pd's canvas for many many reasons.
I had a look at your wrapper code. It is extremely well-organized and readable, btw.
On the one hand, you're giving users/devs a much improved API with which to create and maintain GUI externals. I've been porting Pd to a different toolkit (and completely away from tcl/tk), so I am intimately familiar with the many, many reasons you don't want to use or add to the existing widgetbehavior callbacks.
On the other, your improved API ends in Tk canvas subcommands, and thus inherits all the limitations and bugs of Tk canvas. For simple/limited GUI widgets it's possible to workaround these problems-- in most cases the external developer can hide the problems completely from the end user. But for complex things like a drawing surface those bugs and limitations are exposed fairly directly to the end user.
-Jonathan
You should have a look at the CICM wrapper.
Cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 02/07/15 06:23, Jonathan Wilkes via Pd-list wrote:
On the other, your improved API ends in Tk canvas subcommands, and thus inherits all the limitations and bugs of Tk canvas.
Practically speaking, what is Pierre's alternative? What tradeoffs for user and developer are there in choosing a GUI alternative?
Cheers,
Chris.
On 07/01/2015 09:58 PM, Chris McCormick wrote:
On 02/07/15 06:23, Jonathan Wilkes via Pd-list wrote:
On the other, your improved API ends in Tk canvas subcommands, and thus inherits all the limitations and bugs of Tk canvas.
Practically speaking, what is Pierre's alternative?
I'm not sure yet.
Pierre: what is the syntax for the "path" method, and what does it do?
-Jonathan
What tradeoffs for user and developer are there in choosing a GUI alternative?
Cheers,
Chris.
-
Chris McCormick -
Jonathan Wilkes -
Pierre Guillot