[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