[PD] [PD-dev] tkwidgets

Jonathan Wilkes jancsika at yahoo.com
Fri Aug 26 17:31:22 CEST 2011


It might be a good idea to list the problems with tcl/tk so we can weigh them against the difficulty of using a different GUI toolkit.  The problems I see are:
* difficult to implement a decent zoom function for a canvas
* can't display png without the Img library (included in 8.6)

* can't do alpha transparency


Of the three I listed, I'm mostly interested in the first as it means that (without prior planning) it's hard to take a patch you've been working on at font size 10 and display it adequately over a projector, for example.  (If there's a work around I'd like to know it.)
I'd like to hear others, but I'm mostly interested in problems with tcl/tk >= 8.5 as the GUI.



>________________________________
>From: András Murányi <muranyia at gmail.com>
>To: pd-list <pd-list at iem.at>
>Sent: Thursday, August 25, 2011 8:19 PM
>Subject: Re: [PD] [PD-dev] tkwidgets
>
>
>Yeah and afaiu this is exactly the job that HC just started (see his announcement below).
>Yvan: in my simple understanding it goes like this: 1. getting rid of tcl-specific code in pd c core 2. minimizing the communication between the core and the gui (3. defining the api/protocol?) 4. anyone can go make all sorts of guis for pd... at this point or later on vanilla may or may not switch from tcl - imho it's to be decided when we're there
>
>Andras
>
>
>On Fri, Aug 26, 2011 at 01:39, Jonathan Wilkes <jancsika at yahoo.com> wrote:
>
>The pd/pd-gui divide is a little misleading-- there are lots of places in the c code where there are sys_gui and sys_vgui calls with tcl in them, plus c code that probably assumes tcl is being used on the gui side.
>>You'll either need to write a wrapper for those calls, or modify a lot of c code and basically make a fork (iemguis, canvas stuff, etc.)
>>
>>But even if you write a wrapper, there are still issues that will need to be dealt with on the c side to minimize the number of messages passing back and forth between pd and gui.  For example, there is one call per xlet to the gui when an object gets instantiated/vis'd, plus drawing the border and text, rather than one call per object (and letting the gui deal with where to draw xlets, box width, font,
 etc.).
>>
>>-Jonathan
>>
>>
>>>________________________________
>>>From: yvan volochine <yvan.pd at gmail.com>
>>>
>>>To: Hans-Christoph Steiner <hans at at.or.at>
>>>Cc: Jonathan Wilkes <jancsika at yahoo.com>; pd-dev List <pd-dev at iem.at>
>>>Sent: Thursday, August 25, 2011 6:18 PM
>>>Subject: Re: [PD-dev] tkwidgets
>>>
>>>
>>>On 08/17/2011 08:54 PM, Hans-Christoph Steiner wrote:
>>>> I've started a private git branch of
>>>> tkwidgets
 that I intent to push once I get somewhere with it. The idea
>>>> is to try out a new idea for how GUI objects can work. Basically, I
>>>> think I can make it so that Tcl handles more of the interaction with the
>>>> user, minimizing on pd-gui <--> pd communications, and making it easier
>>>> to write GUI objects. Its not trivial to do, but should be doable.
>>>
>>>hiho
>>>
>>>sorry for bumping in but what about giving up tcl-tk and go on with something more "modern" (à la Qt), with a decent OO interface ?
>>>
>>>I might miss the obvious as I'm new here but what about rewriting pd GUI in Qt ?
>>>wouldn't it make more sense than spending time hacking on and on tcl-tk code ?
>>>
>>>my 0.001$
>>>_y
>>>
>>>
>>>
>>
>
>_______________________________________________
>Pd-list at iem.at mailing list
>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110826/0531becc/attachment-0001.htm>


More information about the Pd-list mailing list