No. They are the same.
Some objects simply have (always had) an offset based on the outline thickness and/or the label. It should be apparent when looking in the code.
The work I did was to fix zooming, import the object sizing from Pd-extended, and fix any bugs I found. I did not change the existing behavior or sizing of the IEM guis (hopefully).
> On Dec 7, 2017, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote:
>
> With libPd, calling the getrect function of the IEM's GUIs gives
> coordinates that seem to be slightly different from what is really drawn.
> I've seen in the Github PR 227 (
> https://github.com/pure-data/pure-data/pull/227 <https://github.com/pure-data/pure-data/pull/227>), that the IEM's GUIs have
> been updated. Do the size and the position of the objects has changed?
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
With libPd, calling the getrect function of the IEM's GUIs gives
coordinates that seem to be slightly different from what is really drawn.
I've seen in the Github PR 227 (
https://github.com/pure-data/pure-data/pull/227), that the IEM's GUIs have
been updated. Do the size and the position of the objects has changed? The
Pd submodule of libPd is behind Pd vanilla, so in this case I should wait
before trying to correct these small offsets in my code. If changes has
been made, does it respect now the Purr-Data "expectations" (see
https://git.purrdata.net/jwilkes/purr-data/issues/243#note_1995)?
Cheers (an thanks for the work!)
Pierre
Sounds good. Let me know if I can help, ie. merge some of the various PRs into a single PR.
> On Nov 30, 2017, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote:
>
> I put this right in 'head' on a clone of my own repo; it compiles OK for me
> here on linux/64 and widows-32 so I think it's provisionally working, but needs
> lots of testing.
>
> If there's no reason not to I'll just throw that all in my own 'head' and push
> it all back to the git repo.
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
I know this comes up from time to time, but I think it would be great if comments would support saving end line characters. The canvas clearly supports it as I can paste in multiline text and it looks great. The end lines are of course gone when reloading the patch.
Since their is already the convention for escaping semis and commas, maybe all we need is to escape and end line. Something like \n?
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
It's an easy fix.
I originally thought creating the app bundle with the full source tree files and the compilation step .o files was a bug and not a feature. The resulting .app is thus smaller. The app bundler script was written before the pd con and I didn't recognize the feature when presented.
I'd say that if Pd is easier to build, we don't need this but I'm probably wrong. At the very least, the header directory can be named back to "src"
> On Aug 15, 2017, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote:
>
> Dan was unaware of this when reorganizing the build scripts for the
> bundle, and while I'm writing this he opened an issue suggesting a
> fix:
> https://github.com/pure-data/pure-data/issues/181 <https://github.com/pure-data/pure-data/issues/181>
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
I can add the architecture to the info string, although I believe IOhannes is adding/has added support for the pd core to send it's compiled arch tire info to the GUI. This is mainly for deken but it would be helpful in general.
The other way to do this is to use the file command ala:
file /Applications/Pd-0.48-0.app/Contents/Resources/bin
> On Dec 1, 2017, at 6:44 PM, pd-dev-request(a)lists.iem.at wrote:
>
> Date: Fri, 1 Dec 2017 12:44:21 -0500
> From: Federico Camara Halac <camarafede(a)gmail.com <mailto:camarafede@gmail.com>>
> Cc: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>
> Subject: Re: [PD-dev] Pd macOS app naming
> Message-ID:
> <CAO_HSB4w9V-tneT7cYcEwNd8=JWUB_Av0gzdetv7_GDX=03XVw(a)mail.gmail.com <mailto:CAO_HSB4w9V-tneT7cYcEwNd8=JWUB_Av0gzdetv7_GDX=03XVw@mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
>
> Pd.app would be fine, yes. But, i think some flag should be added to
> distinguish 32 from 64 bit versions, like the current *-i386.app one, or
> simply Pd-32.app. This would be helpful when using Gem on OSX, for example.
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>