[PD-dev] Pd-extended-0.43 appearance

Hans-Christoph Steiner hans at at.or.at
Sat Oct 22 22:15:39 CEST 2011


On Oct 22, 2011, at 12:34 PM, Jonathan Wilkes wrote:

>
>
>
>
> ----- Original Message -----
>> From: Hans-Christoph Steiner <hans at at.or.at>
>> To: Jonathan Wilkes <jancsika at yahoo.com>
>> Cc: Miller Puckette <msp at ucsd.edu>; "pd-dev at iem.at" <pd-dev at iem.at>
>> Sent: Saturday, October 22, 2011 12:49 AM
>> Subject: Re: [PD-dev] Pd-extended-0.43 appearance
>>
>>
>> On Oct 21, 2011, at 11:56 PM, Jonathan Wilkes wrote:
>>
>>> ----- Original Message -----
>>>
>>>> From: Hans-Christoph Steiner <hans at at.or.at>
>>>> To: Miller Puckette <msp at ucsd.edu>
>>>> Cc: pd-dev at iem.at
>>>> Sent: Friday, October 21, 2011 11:33 PM
>>>> Subject: Re: [PD-dev] Pd-extended-0.43 appearance
>>>>
>>>>
>>>> That would be great, to make it really work well, we need to move  
>>>> as
>> much of the
>>>> GUI handling to pd-gui and have pd talk only using pd messages.  So
>> something
>>>> like this:
>>>>
>>>> pd-gui
>>>> ------
>>>> \ click in a box to edit the text
>>>> \ edit the text in the box "osc~ 500"
>>>>    \ click on canvas to create the new object
>>>>     \ pd-gui sends message to pd
>>>> pd
>>>> --
>>>> \ pd receives ".x872342 updateobj 5 osc~ 500
>>>>    \ pd recreates obj #5 with "osc~ 500"
>>>>
>>>> Things like that.  This also means that we can use Tk's built-in
>> zooming
>>>> support, so we can have patches be fully zoomable to any arbitrary
>> size.
>>>
>>> If you're talking about the canvas scale subcommand, keep in mind  
>>> that
>>> fonts and bitmaps don't get scaled.
>>
>> I'm talking about tk scaling.  I am pretty sure fonts get scaled,  
>> but I
>> don't know about bitmaps.
>
> Oh.  Fonts specified in point size will get scaled using the tk  
> scale subcommand,
> but fonts in pixel size (i.e., specified as negative numbers) will  
> not.
>
> Also keep in mind that pd boxes and xlets (and custom guis) are  
> specified with
> pixel coordinates and don't get scaled by using [tk scale].

Yup, that font pixel stuff is necessary because of the way Pd is  
currently architected.  That would all be removed when moving the GUI  
handling out of 'pd' to 'pd-gui'.  I think this is the next big thing  
that Pd needs.  It will have a lot of benefits, like people being able  
to write Pd GUIs using whatever toolkit they want.

Custom GUI objects would be the tricky part.  But in my opinion,  
offloading all of the GUI drawing, mouse handlings, etc. to pd-gui  
will make it so much easier to write GUI objects that will be less  
work just rewriting the existing ones than trying to make good new  
ones like filterview.

On Oct 22, 2011, at 7:51 AM, yvan volochine wrote:

> On 10/21/2011 11:15 PM, Hans-Christoph Steiner wrote:
>> - or, even better, make pd send pd messages to pd-gui instead of Tcl,
>> and move GUI size, mouse, click, etc handling to pd-gui. Then we get
>> zoomable GUIs and all sorts of other good things. Big project tho
>
> this would be really neat indeed.
> do some of you devs already have plans to do that ?
> I'd love to help but won't have much free time before december :/

And to answer Yvan's question, I'd also like to work on this, but  
don't have time now.  I think its a matter of laying out some  
approaches and getting people to work on it when they can.  My current  
approach is to try to tackle one section at a time.  I recently posted  
a patch that moved cord drawing to Tcl, for example.  There are lots  
of little things like that which are good to start with.  Moving click  
handling to the GUI will be a much bigger process.


.hc



----------------------------------------------------------------------------

You can't steal a gift. Bird gave the world his music, and if you can  
hear it, you can have it. - Dizzy Gillespie






More information about the Pd-dev mailing list