Hi Hans
I noticed a significant difference between Pd-extended-0.43 and Pd-vanilla-0.43 appearance. Symbol- and Numberboxes are 2 px higher in Extended than in Vanilla. This is especially problematic in cases where a GOP-patch in Vanilla was created so that the number/symbol box perfectly fits in. The same GOP-abstraction in Pd-extended does not show the number/symbol box at all, because it is overlapping the GOP area of the abstraction.
I also noticed that Pd-extended-0.43 on OS X does not use anti-aliased fonts, although it is (I think) using Tcl/Tk 8.5, while Pd-vanilla-0.43 does use anti-aliased fonts.
On Ubuntu both, Pd-extended and Pd-vanilla 0.43, do use anti-aliased fonts.
Roman
On Oct 21, 2011, at 5:49 AM, Roman Haefeli wrote:
Hi Hans
I noticed a significant difference between Pd-extended-0.43 and Pd-vanilla-0.43 appearance. Symbol- and Numberboxes are 2 px higher in Extended than in Vanilla. This is especially problematic in cases where a GOP-patch in Vanilla was created so that the number/symbol box perfectly fits in. The same GOP-abstraction in Pd-extended does not show the number/symbol box at all, because it is overlapping the GOP area of the abstraction.
I measured a default number box on Pd-extended 0.42.5 and 0.43. They both were 21x39 pixels at 12 point font size. I don't know the details of the current state of this stuff in vanilla, but in Pd- extended, these sizes have been consistent across platform and version since 0.41 at least.
I also noticed that Pd-extended-0.43 on OS X does not use anti-aliased fonts, although it is (I think) using Tcl/Tk 8.5, while Pd- vanilla-0.43 does use anti-aliased fonts.
On Ubuntu both, Pd-extended and Pd-vanilla 0.43, do use anti-aliased fonts.
That's an odd bug I've never seen. Pd-extended on Mac OS X has had anti-aliased fonts for a long time (0.40?) and it does on every Mac I've seen it on. Can you post a screenshot?
----------------------------------------------------------------------------
"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White
On Fri, 2011-10-21 at 12:33 -0400, Hans-Christoph Steiner wrote:
On Oct 21, 2011, at 5:49 AM, Roman Haefeli wrote:
Hi Hans
I noticed a significant difference between Pd-extended-0.43 and Pd-vanilla-0.43 appearance. Symbol- and Numberboxes are 2 px higher in Extended than in Vanilla. This is especially problematic in cases where a GOP-patch in Vanilla was created so that the number/symbol box perfectly fits in. The same GOP-abstraction in Pd-extended does not show the number/symbol box at all, because it is overlapping the GOP area of the abstraction.
I measured a default number box on Pd-extended 0.42.5 and 0.43. They both were 21x39 pixels at 12 point font size. I don't know the details of the current state of this stuff in vanilla, but in Pd- extended, these sizes have been consistent across platform and version since 0.41 at least.
I totally believe you that Pd-extended was consistent to itself since 0.41. Still, the difference renders certain patches/abstractions somehow unportable between the two (extended and vanilla). What do you think would be the best way to deal with that?
I also noticed that Pd-extended-0.43 on OS X does not use anti-aliased fonts, although it is (I think) using Tcl/Tk 8.5, while Pd- vanilla-0.43 does use anti-aliased fonts.
On Ubuntu both, Pd-extended and Pd-vanilla 0.43, do use anti-aliased fonts.
That's an odd bug I've never seen. Pd-extended on Mac OS X has had anti-aliased fonts for a long time (0.40?) and it does on every Mac I've seen it on. Can you post a screenshot?
Probably it's a very recent regression bug. The oldest autobuild of Pd-extended-0.43 I tested was probably a week old. Actually, on all (probably 5 different?) OS X machines I tested the new builds on the fonts were aliased. But it could well be, that all the machines were 10.6.X (don't know if that matters).
Attached two screenshots taken from the same machine, one from Pd-extended0-42.5 and one from Pd-extended-0.43.1
Roman
On Fri, 2011-10-21 at 22:24 +0200, Roman Haefeli wrote:
On Fri, 2011-10-21 at 12:33 -0400, Hans-Christoph Steiner wrote:
On Oct 21, 2011, at 5:49 AM, Roman Haefeli wrote:
I also noticed that Pd-extended-0.43 on OS X does not use anti-aliased fonts, although it is (I think) using Tcl/Tk 8.5, while Pd- vanilla-0.43 does use anti-aliased fonts.
On Ubuntu both, Pd-extended and Pd-vanilla 0.43, do use anti-aliased fonts.
That's an odd bug I've never seen. Pd-extended on Mac OS X has had anti-aliased fonts for a long time (0.40?) and it does on every Mac I've seen it on. Can you post a screenshot?
Probably it's a very recent regression bug. The oldest autobuild of Pd-extended-0.43 I tested was probably a week old. Actually, on all (probably 5 different?) OS X machines I tested the new builds on the fonts were aliased. But it could well be, that all the machines were 10.6.X (don't know if that matters).
Attached two screenshots taken from the same machine, one from Pd-extended0-42.5 and one from Pd-extended-0.43.1
I also should add that only the objects, messages, number and symbol boxes are aliased. All the iemguis have anti-aliased fonts. (I noticed only now, otherwise I'd have included some in the screenshots).
Roman
On Oct 21, 2011, at 4:31 PM, Roman Haefeli wrote:
On Fri, 2011-10-21 at 22:24 +0200, Roman Haefeli wrote:
On Fri, 2011-10-21 at 12:33 -0400, Hans-Christoph Steiner wrote:
On Oct 21, 2011, at 5:49 AM, Roman Haefeli wrote:
I also noticed that Pd-extended-0.43 on OS X does not use anti- aliased fonts, although it is (I think) using Tcl/Tk 8.5, while Pd- vanilla-0.43 does use anti-aliased fonts.
On Ubuntu both, Pd-extended and Pd-vanilla 0.43, do use anti- aliased fonts.
That's an odd bug I've never seen. Pd-extended on Mac OS X has had anti-aliased fonts for a long time (0.40?) and it does on every Mac I've seen it on. Can you post a screenshot?
Probably it's a very recent regression bug. The oldest autobuild of Pd-extended-0.43 I tested was probably a week old. Actually, on all (probably 5 different?) OS X machines I tested the new builds on the fonts were aliased. But it could well be, that all the machines were 10.6.X (don't know if that matters).
Attached two screenshots taken from the same machine, one from Pd-extended0-42.5 and one from Pd-extended-0.43.1
I also should add that only the objects, messages, number and symbol boxes are aliased. All the iemguis have anti-aliased fonts. (I noticed only now, otherwise I'd have included some in the screenshots).
Looks like the screenshots didn't make it on the email.
.hc
----------------------------------------------------------------------------
I hate it when they say, "He gave his life for his country." Nobody gives their life for anything. We steal the lives of these kids. - Admiral Gene LeRocque
On Fri, Oct 21, 2011 at 04:58:42PM -0400, Hans-Christoph Steiner wrote:
Looks like the screenshots didn't make it on the email.
See the links at the bottom:
http://lists.puredata.info/pipermail/pd-dev/2011-10/017657.html
Marvin Humphrey
On Oct 21, 2011, at 4:24 PM, Roman Haefeli wrote:
On Fri, 2011-10-21 at 12:33 -0400, Hans-Christoph Steiner wrote:
On Oct 21, 2011, at 5:49 AM, Roman Haefeli wrote:
Hi Hans
I noticed a significant difference between Pd-extended-0.43 and Pd-vanilla-0.43 appearance. Symbol- and Numberboxes are 2 px higher in Extended than in Vanilla. This is especially problematic in cases where a GOP-patch in Vanilla was created so that the number/symbol box perfectly fits in. The same GOP-abstraction in Pd-extended does not show the number/symbol box at all, because it is overlapping the GOP area of the abstraction.
I measured a default number box on Pd-extended 0.42.5 and 0.43. They both were 21x39 pixels at 12 point font size. I don't know the details of the current state of this stuff in vanilla, but in Pd- extended, these sizes have been consistent across platform and version since 0.41 at least.
I totally believe you that Pd-extended was consistent to itself since 0.41. Still, the difference renders certain patches/abstractions somehow unportable between the two (extended and vanilla). What do you think would be the best way to deal with that?
IMHO, it would be two things:
- make Pd vanilla do what Pd-extended does in terms of box sizing
- 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
I also noticed that Pd-extended-0.43 on OS X does not use anti- aliased fonts, although it is (I think) using Tcl/Tk 8.5, while Pd- vanilla-0.43 does use anti-aliased fonts.
On Ubuntu both, Pd-extended and Pd-vanilla 0.43, do use anti-aliased fonts.
That's an odd bug I've never seen. Pd-extended on Mac OS X has had anti-aliased fonts for a long time (0.40?) and it does on every Mac I've seen it on. Can you post a screenshot?
Probably it's a very recent regression bug. The oldest autobuild of Pd-extended-0.43 I tested was probably a week old. Actually, on all (probably 5 different?) OS X machines I tested the new builds on the fonts were aliased. But it could well be, that all the machines were 10.6.X (don't know if that matters).
Attached two screenshots taken from the same machine, one from Pd-extended0-42.5 and one from Pd-extended-0.43.1
Roman
<aliased.png><anti-aliased.png>
Ah, I see. It turns out that 0.43 is actually correct. If you compare the same text in a native Mac OS X program like TextEdit, use plain text mode, and make sure its using Monaco for the font. Then you'll see that 0.43 is actually the same as TextEdit, while in 0.42, the font is slightly smaller than it should be, therefore looking fuzzy or anti-aliases. Monaco is a font that is not anti-aliased at many sizes.
.hc
----------------------------------------------------------------------------
kill your television
On Fri, 2011-10-21 at 17:15 -0400, Hans-Christoph Steiner wrote:
On Oct 21, 2011, at 4:24 PM, Roman Haefeli wrote:
On Fri, 2011-10-21 at 12:33 -0400, Hans-Christoph Steiner wrote:
On Oct 21, 2011, at 5:49 AM, Roman Haefeli wrote:
Hi Hans
I noticed a significant difference between Pd-extended-0.43 and Pd-vanilla-0.43 appearance. Symbol- and Numberboxes are 2 px higher in Extended than in Vanilla. This is especially problematic in cases where a GOP-patch in Vanilla was created so that the number/symbol box perfectly fits in. The same GOP-abstraction in Pd-extended does not show the number/symbol box at all, because it is overlapping the GOP area of the abstraction.
I measured a default number box on Pd-extended 0.42.5 and 0.43. They both were 21x39 pixels at 12 point font size. I don't know the details of the current state of this stuff in vanilla, but in Pd- extended, these sizes have been consistent across platform and version since 0.41 at least.
I totally believe you that Pd-extended was consistent to itself since 0.41. Still, the difference renders certain patches/abstractions somehow unportable between the two (extended and vanilla). What do you think would be the best way to deal with that?
IMHO, it would be two things:
- make Pd vanilla do what Pd-extended does in terms of box sizing
1) Why does Pd-vanilla have to adapt itself to Pd-extended (and not vice versa)?
2) What is it that Pd-extended does in terms of box sizing?
3) Is there any way I can help with that?
- 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
Sorry, I think I am not able to help with that.
Roman
On Oct 21, 2011, at 6:29 PM, Roman Haefeli wrote:
On Fri, 2011-10-21 at 17:15 -0400, Hans-Christoph Steiner wrote:
On Oct 21, 2011, at 4:24 PM, Roman Haefeli wrote:
On Fri, 2011-10-21 at 12:33 -0400, Hans-Christoph Steiner wrote:
On Oct 21, 2011, at 5:49 AM, Roman Haefeli wrote:
Hi Hans
I noticed a significant difference between Pd-extended-0.43 and Pd-vanilla-0.43 appearance. Symbol- and Numberboxes are 2 px higher in Extended than in Vanilla. This is especially problematic in cases where a GOP-patch in Vanilla was created so that the number/symbol box perfectly fits in. The same GOP-abstraction in Pd-extended does not show the number/symbol box at all, because it is overlapping the GOP area of the abstraction.
I measured a default number box on Pd-extended 0.42.5 and 0.43. They both were 21x39 pixels at 12 point font size. I don't know the details of the current state of this stuff in vanilla, but in Pd- extended, these sizes have been consistent across platform and version since 0.41 at least.
I totally believe you that Pd-extended was consistent to itself since 0.41. Still, the difference renders certain patches/abstractions somehow unportable between the two (extended and vanilla). What do you think would be the best way to deal with that?
IMHO, it would be two things:
- make Pd vanilla do what Pd-extended does in terms of box sizing
- Why does Pd-vanilla have to adapt itself to Pd-extended (and not
vice versa)?
What is it that Pd-extended does in terms of box sizing?
Is there any way I can help with that?
- 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
Sorry, I think I am not able to help with that.
Roman
Pd vanilla still has different box sizes on different platforms, if I remember correctly, therefore the sizes will have to change somewhere.
I tried to get these changes into vanilla, but I guess Miller didn't want them. I've already spent a lot of time on it, so I've moved on since it works in Pd-extended. There should be a whole history of the discussion on pd-dev, i.e. the details of the issues. I don't remember them, I'm sure it was some annoying technical details.
Also, you can see the changes that pd-extended makes to puredata but looking at the pd-extended.git in the 'patch_series' branch.
.hc
----------------------------------------------------------------------------
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
On Fri, 2011-10-21 at 18:36 -0400, Hans-Christoph Steiner wrote:
On Oct 21, 2011, at 6:29 PM, Roman Haefeli wrote:
On Fri, 2011-10-21 at 17:15 -0400, Hans-Christoph Steiner wrote:
On Oct 21, 2011, at 4:24 PM, Roman Haefeli wrote:
On Fri, 2011-10-21 at 12:33 -0400, Hans-Christoph Steiner wrote:
On Oct 21, 2011, at 5:49 AM, Roman Haefeli wrote:
Hi Hans
I noticed a significant difference between Pd-extended-0.43 and Pd-vanilla-0.43 appearance. Symbol- and Numberboxes are 2 px higher in Extended than in Vanilla. This is especially problematic in cases where a GOP-patch in Vanilla was created so that the number/symbol box perfectly fits in. The same GOP-abstraction in Pd-extended does not show the number/symbol box at all, because it is overlapping the GOP area of the abstraction.
I measured a default number box on Pd-extended 0.42.5 and 0.43. They both were 21x39 pixels at 12 point font size. I don't know the details of the current state of this stuff in vanilla, but in Pd- extended, these sizes have been consistent across platform and version since 0.41 at least.
I totally believe you that Pd-extended was consistent to itself since 0.41. Still, the difference renders certain patches/abstractions somehow unportable between the two (extended and vanilla). What do you think would be the best way to deal with that?
IMHO, it would be two things:
- make Pd vanilla do what Pd-extended does in terms of box sizing
- Why does Pd-vanilla have to adapt itself to Pd-extended (and not
vice versa)?
What is it that Pd-extended does in terms of box sizing?
Is there any way I can help with that?
- 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
Sorry, I think I am not able to help with that.
Roman
Pd vanilla still has different box sizes on different platforms, if I remember correctly, therefore the sizes will have to change somewhere.
I'll check that again. It seemed to me that the Pd-vanilla looked very much the same on OS X and Linux, at least since 0.43. I haven't checked Windows yet. Also I had the impression that Pd-vanilla doesn't have a different appearance across different Linuxes anymore. I remember it being dependent on some DPI setting, but I haven't encountered that issue anymore.
I tried to get these changes into vanilla, but I guess Miller didn't want them. I've already spent a lot of time on it, so I've moved on since it works in Pd-extended. There should be a whole history of the discussion on pd-dev, i.e. the details of the issues. I don't remember them, I'm sure it was some annoying technical details.
Also, you can see the changes that pd-extended makes to puredata but looking at the pd-extended.git in the 'patch_series' branch.
Thanks for the explanations.
Roman
Last I checked things were completely inconsistent and no version ("normal" or extended) got the same font sizes across platforms. If anyone can figure out how to make that work robustly I'm all for it. One headache is that I've tried to make PD use natively available fonts which everyone will have - and there simply don't seem to be natively available fonts with comparable sizes between Pc/Mac/linux.
cheers Miller
I'll check that again. It seemed to me that the Pd-vanilla looked very much the same on OS X and Linux, at least since 0.43. I haven't checked Windows yet. Also I had the impression that Pd-vanilla doesn't have a different appearance across different Linuxes anymore. I remember it being dependent on some DPI setting, but I haven't encountered that issue anymore.
I tried to get these changes into vanilla, but I guess Miller didn't want them. I've already spent a lot of time on it, so I've moved on since it works in Pd-extended. There should be a whole history of the discussion on pd-dev, i.e. the details of the issues. I don't remember them, I'm sure it was some annoying technical details.
Also, you can see the changes that pd-extended makes to puredata but looking at the pd-extended.git in the 'patch_series' branch.
Thanks for the explanations.
Roman
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
I think we're talking about the box sizes rather than the font sizes. Those can just be hard-coded to a certain size in pixels, then the font can be measured to fit into those boxes. That's the approach that Pd-extended has been doing since 0.41 or 0.40, I forget which. That's how it works in Pd vanilla 0.43 too.
To handle font size differences, the box sizing needs to be handled in Tcl, as well as the mouse and click handling. For something like clicking to edit an object box, Pd only needs to know what the new text is once the editing is done.
Roman, I think the thing to do is to measure the boxes for each release in question on each platform so we know where the problem lies. That's what I did back in the day to make the boxes the same pixel sizes.
.hc
On Oct 21, 2011, at 7:02 PM, Miller Puckette wrote:
Last I checked things were completely inconsistent and no version ("normal" or extended) got the same font sizes across platforms. If anyone can figure out how to make that work robustly I'm all for it. One headache is that I've tried to make PD use natively available fonts which everyone will have - and there simply don't seem to be natively available fonts with comparable sizes between Pc/Mac/linux.
cheers Miller
I'll check that again. It seemed to me that the Pd-vanilla looked very much the same on OS X and Linux, at least since 0.43. I haven't checked Windows yet. Also I had the impression that Pd-vanilla doesn't have a different appearance across different Linuxes anymore. I remember it being dependent on some DPI setting, but I haven't encountered that issue anymore.
I tried to get these changes into vanilla, but I guess Miller didn't want them. I've already spent a lot of time on it, so I've moved on since it works in Pd-extended. There should be a whole history of the discussion on pd-dev, i.e. the details of the issues. I don't remember them, I'm sure it was some annoying technical details.
Also, you can see the changes that pd-extended makes to puredata but looking at the pd-extended.git in the 'patch_series' branch.
Thanks for the explanations.
Roman
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
Oh -- I misunderstood.
I like the idea of making this an option (eitehr growing to the standard box size or huggung the actual size of the font we're getting).
cheers Miller
On Fri, Oct 21, 2011 at 07:43:17PM -0400, Hans-Christoph Steiner wrote:
I think we're talking about the box sizes rather than the font sizes. Those can just be hard-coded to a certain size in pixels, then the font can be measured to fit into those boxes. That's the approach that Pd-extended has been doing since 0.41 or 0.40, I forget which. That's how it works in Pd vanilla 0.43 too.
To handle font size differences, the box sizing needs to be handled in Tcl, as well as the mouse and click handling. For something like clicking to edit an object box, Pd only needs to know what the new text is once the editing is done.
Roman, I think the thing to do is to measure the boxes for each release in question on each platform so we know where the problem lies. That's what I did back in the day to make the boxes the same pixel sizes.
.hc
On Oct 21, 2011, at 7:02 PM, Miller Puckette wrote:
Last I checked things were completely inconsistent and no version ("normal" or extended) got the same font sizes across platforms. If anyone can figure out how to make that work robustly I'm all for it. One headache is that I've tried to make PD use natively available fonts which everyone will have - and there simply don't seem to be natively available fonts with comparable sizes between Pc/Mac/linux.
cheers Miller
I'll check that again. It seemed to me that the Pd-vanilla looked very much the same on OS X and Linux, at least since 0.43. I haven't checked Windows yet. Also I had the impression that Pd-vanilla doesn't have a different appearance across different Linuxes anymore. I remember it being dependent on some DPI setting, but I haven't encountered that issue anymore.
I tried to get these changes into vanilla, but I guess Miller didn't want them. I've already spent a lot of time on it, so I've moved on since it works in Pd-extended. There should be a whole history of the discussion on pd-dev, i.e. the details of the issues. I don't remember them, I'm sure it was some annoying technical details.
Also, you can see the changes that pd-extended makes to puredata but looking at the pd-extended.git in the 'patch_series' branch.
Thanks for the explanations.
Roman
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
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.
.hc
On Oct 21, 2011, at 7:48 PM, Miller Puckette wrote:
Oh -- I misunderstood.
I like the idea of making this an option (eitehr growing to the standard box size or huggung the actual size of the font we're getting).
cheers Miller
On Fri, Oct 21, 2011 at 07:43:17PM -0400, Hans-Christoph Steiner wrote:
I think we're talking about the box sizes rather than the font sizes. Those can just be hard-coded to a certain size in pixels, then the font can be measured to fit into those boxes. That's the approach that Pd-extended has been doing since 0.41 or 0.40, I forget which. That's how it works in Pd vanilla 0.43 too.
To handle font size differences, the box sizing needs to be handled in Tcl, as well as the mouse and click handling. For something like clicking to edit an object box, Pd only needs to know what the new text is once the editing is done.
Roman, I think the thing to do is to measure the boxes for each release in question on each platform so we know where the problem lies. That's what I did back in the day to make the boxes the same pixel sizes.
.hc
On Oct 21, 2011, at 7:02 PM, Miller Puckette wrote:
Last I checked things were completely inconsistent and no version ("normal" or extended) got the same font sizes across platforms. If anyone can figure out how to make that work robustly I'm all for it. One headache is that I've tried to make PD use natively available fonts which everyone will have - and there simply don't seem to be natively available fonts with comparable sizes between Pc/Mac/linux.
cheers Miller
I'll check that again. It seemed to me that the Pd-vanilla looked very much the same on OS X and Linux, at least since 0.43. I haven't checked Windows yet. Also I had the impression that Pd-vanilla doesn't have a different appearance across different Linuxes anymore. I remember it being dependent on some DPI setting, but I haven't encountered that issue anymore.
I tried to get these changes into vanilla, but I guess Miller didn't want them. I've already spent a lot of time on it, so I've moved on since it works in Pd-extended. There should be a whole history of the discussion on pd-dev, i.e. the details of the issues. I don't remember them, I'm sure it was some annoying technical details.
Also, you can see the changes that pd-extended makes to puredata but looking at the pd-extended.git in the 'patch_series' branch.
Thanks for the explanations.
Roman
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
----------------------------------------------------------------------------
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Miller Puckette msp@ucsd.edu Cc: pd-dev@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.
Also, you stated below that box sizes are hard coded in both (current) extended and vanilla. Does that include box width? If so, that would mean that the entire pd diagram-- except for the specific font used-- would appear pixel exact on any platform. But the OP is to the contrary, so does hard-coded mean minimums are set and extra space is allotted as needed?
Maybe a better question is-- could you point me to the spot where the hard-coded values are specified?
-Jonathan
.hc
On Oct 21, 2011, at 7:48 PM, Miller Puckette wrote:
Oh -- I misunderstood.
I like the idea of making this an option (eitehr growing to the standard box size or huggung the actual size of the font we're getting).
cheers Miller
On Fri, Oct 21, 2011 at 07:43:17PM -0400, Hans-Christoph Steiner wrote:
I think we're talking about the box sizes rather than the font
sizes.
Those can just be hard-coded to a certain size in pixels, then the font can be measured to fit into those boxes. That's the approach that Pd-extended has been doing since 0.41 or 0.40, I forget which.
That's
how it works in Pd vanilla 0.43 too.
To handle font size differences, the box sizing needs to be handled in Tcl, as well as the mouse and click handling. For something like clicking to edit an object box, Pd only needs to know what the new text is once the editing is done.
Roman, I think the thing to do is to measure the boxes for each release in question on each platform so we know where the problem lies.
That's
what I did back in the day to make the boxes the same pixel sizes.
.hc
On Oct 21, 2011, at 7:02 PM, Miller Puckette wrote:
Last I checked things were completely inconsistent and no version ("normal" or extended) got the same font sizes across platforms. If anyone
can
figure out how to make that work robustly I'm all for it. One headache is that I've tried to make PD use natively available fonts
which
everyone will have - and there simply don't seem to be natively
available fonts
with comparable sizes between Pc/Mac/linux.
cheers Miller
I'll check that again. It seemed to me that the Pd-vanilla
looked
very much the same on OS X and Linux, at least since 0.43. I
haven't
checked Windows yet. Also I had the impression that Pd-vanilla
doesn't have a
different appearance across different Linuxes anymore. I
remember it
being dependent on some DPI setting, but I haven't
encountered that
issue anymore.
I tried to get these changes into vanilla, but I guess
Miller didn't
want them. I've already spent a lot of time on it, so
I've moved on
since it works in Pd-extended. There should be a whole
history of
the discussion on pd-dev, i.e. the details of the issues. I
don't
remember them, I'm sure it was some annoying technical
details.
Also, you can see the changes that pd-extended makes to
puredata but
looking at the pd-extended.git in the
'patch_series' branch.
Thanks for the explanations.
Roman
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
'You people have such restrictive dress for women,’ she said,
hobbling
away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Oct 21, 2011, at 11:56 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Miller Puckette msp@ucsd.edu Cc: pd-dev@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.
Also, you stated below that box sizes are hard coded in both (current) extended and vanilla. Does that include box width? If so, that would mean that the entire pd diagram-- except for the specific font used-- would appear pixel exact on any platform. But the OP is to the contrary, so does hard-coded mean minimums are set and extra space is allotted as needed?
The sizes are specified per character.
Maybe a better question is-- could you point me to the spot where the hard-coded values are specified?
tcl/pd-gui.tcl, see font_fixed_metrics
.hc
-Jonathan
.hc
On Oct 21, 2011, at 7:48 PM, Miller Puckette wrote:
Oh -- I misunderstood.
I like the idea of making this an option (eitehr growing to the standard box size or huggung the actual size of the font we're getting).
cheers Miller
On Fri, Oct 21, 2011 at 07:43:17PM -0400, Hans-Christoph Steiner wrote:
I think we're talking about the box sizes rather than the font
sizes.
Those can just be hard-coded to a certain size in pixels, then the font can be measured to fit into those boxes. That's the approach that Pd-extended has been doing since 0.41 or 0.40, I forget which.
That's
how it works in Pd vanilla 0.43 too.
To handle font size differences, the box sizing needs to be handled in Tcl, as well as the mouse and click handling. For something like clicking to edit an object box, Pd only needs to know what the new text is once the editing is done.
Roman, I think the thing to do is to measure the boxes for each release in question on each platform so we know where the problem lies.
That's
what I did back in the day to make the boxes the same pixel sizes.
.hc
On Oct 21, 2011, at 7:02 PM, Miller Puckette wrote:
Last I checked things were completely inconsistent and no version ("normal" or extended) got the same font sizes across platforms. If anyone
can
figure out how to make that work robustly I'm all for it. One headache is that I've tried to make PD use natively available fonts
which
everyone will have - and there simply don't seem to be natively
available fonts
with comparable sizes between Pc/Mac/linux.
cheers Miller
I'll check that again. It seemed to me that the Pd-vanilla
looked
very much the same on OS X and Linux, at least since 0.43. I
haven't
checked Windows yet. Also I had the impression that Pd-vanilla
doesn't have a
different appearance across different Linuxes anymore. I
remember it
being dependent on some DPI setting, but I haven't
encountered that
issue anymore.
> I tried to get these changes into vanilla, but I guess
Miller didn't
> want them. I've already spent a lot of time on it, so
I've moved on
> since it works in Pd-extended. There should be a whole
history of
> the > discussion on pd-dev, i.e. the details of the issues. I
don't
> remember them, I'm sure it was some annoying technical
details.
> > Also, you can see the changes that pd-extended makes to
puredata but
> looking at the pd-extended.git in the
'patch_series' branch.
Thanks for the explanations.
Roman
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
'You people have such restrictive dress for women,’ she said,
hobbling
away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Miller Puckette msp@ucsd.edu; "pd-dev@iem.at" pd-dev@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.or.at To: Miller Puckette msp@ucsd.edu Cc: pd-dev@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].
Also, you stated below that box sizes are hard coded in both (current)
extended and
vanilla. Does that include box width? If so, that would mean that the
entire pd
diagram-- except for the specific font used-- would appear pixel exact on
any
platform. But the OP is to the contrary, so does hard-coded mean minimums
are
set and extra space is allotted as needed?
The sizes are specified per character.
Maybe a better question is-- could you point me to the spot where the
hard-coded
values are specified?
tcl/pd-gui.tcl, see font_fixed_metrics
.hc
-Jonathan
.hc
On Oct 21, 2011, at 7:48 PM, Miller Puckette wrote:
Oh -- I misunderstood.
I like the idea of making this an option (eitehr growing to the
standard
box size or huggung the actual size of the font we're getting).
cheers Miller
On Fri, Oct 21, 2011 at 07:43:17PM -0400, Hans-Christoph Steiner
wrote:
I think we're talking about the box sizes rather than the
font
sizes.
Those can just be hard-coded to a certain size in pixels, then
the font
can be measured to fit into those boxes. That's the
approach that
Pd-extended has been doing since 0.41 or 0.40, I forget which.
That's
how it works in Pd vanilla 0.43 too.
To handle font size differences, the box sizing needs to be
handled in
Tcl, as well as the mouse and click handling. For something
like
clicking to edit an object box, Pd only needs to know what the
new text
is once the editing is done.
Roman, I think the thing to do is to measure the boxes for each
release
in question on each platform so we know where the problem lies.
That's
what I did back in the day to make the boxes the same pixel
sizes.
.hc
On Oct 21, 2011, at 7:02 PM, Miller Puckette wrote:
Last I checked things were completely inconsistent and no
version
("normal" or extended) got the same font sizes across platforms. If
anyone
can
figure out how to make that work robustly I'm all for
it. One
headache is that I've tried to make PD use natively available
fonts
which
everyone will have - and there simply don't seem to be natively
available fonts
with comparable sizes between Pc/Mac/linux.
cheers Miller
> > I'll check that again. It seemed to me that the
Pd-vanilla
looked
> very > much the same on OS X and Linux, at least since 0.43. I
haven't
> checked > Windows yet. Also I had the impression that Pd-vanilla
doesn't have a
> different appearance across different Linuxes anymore.
I
remember it
> being dependent on some DPI setting, but I haven't
encountered that
> issue anymore. > >> I tried to get these changes into vanilla, but I
guess
Miller didn't
>> want them. I've already spent a lot of time on
it, so
I've moved on
>> since it works in Pd-extended. There should be a
whole
history of
>> the >> discussion on pd-dev, i.e. the details of the
issues. I
don't
>> remember them, I'm sure it was some annoying
technical
details.
>> >> Also, you can see the changes that pd-extended
makes to
puredata but
>> looking at the pd-extended.git in the
'patch_series' branch.
> > Thanks for the explanations. > > Roman > > > > > _______________________________________________ > Pd-dev mailing list > Pd-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev
'You people have such restrictive dress for women,’ she
said,
hobbling
away in three inch heels and panty hose to finish out another
pink-
collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
If nature has made any one thing less susceptible than all others of
exclusive
property, it is the action of the thinking power called an idea, which
an
individual may exclusively possess as long as he keeps it to himself;
but the
moment it is divulged, it forces itself into the possession of
everyone, and the
receiver cannot dispossess himself of it. - Thomas Jefferson
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson
On Oct 22, 2011, at 12:34 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Miller Puckette msp@ucsd.edu; "pd-dev@iem.at" pd-dev@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.or.at To: Miller Puckette msp@ucsd.edu Cc: pd-dev@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
On Fri, 2011-10-21 at 18:36 -0400, Hans-Christoph Steiner wrote:
Pd vanilla still has different box sizes on different platforms, if I remember correctly, therefore the sizes will have to change somewhere.
I made a little test patch and took screenshots [1]. On three operating systems (Mac OS 10.6.4, Ubuntu 10.04, Windows 7) I tested Pd-extended-0.43.1 (from autobuilds) and Pd-0.43.1test4 (from Miller's site).
The results are contrary to what you are saying. For Pd-0.43.1test4 the box sizes are consistent across all tested platforms. For Pd-extended-0.43.1 the number, symbol, message and object boxes are 2 px less tall on Windows than on the other platforms. Due to this, only on Windows number and symbol boxes have the same height in Pd-vanilla and Pd-extended (though message and object boxes are 2px smaller in Pd-extended than in Pd-vanilla).
On the other two platforms, Ubuntu 10.04 and OS X, number and symbol boxes are 2 px taller in Pd-extended than in Pd-vanilla.
The hsliders, vsliders and cnvs have the exact same dimensions in every tested combination. Also is the width of number, symbol, message and object boxes consistent across all tested platforms and flavors.
I tried to get these changes into vanilla, but I guess Miller didn't want them.
Currently, it looks like they are not necessary since the situation looks good for Pd-vanilla.
I've already spent a lot of time on it, so I've moved on since it works in Pd-extended. There should be a whole history of the discussion on pd-dev, i.e. the details of the issues. I don't remember them, I'm sure it was some annoying technical details.
Since only Pd-extended is not consistent across platforms, would that be reason enough to reconsider adapting Pd-extended to the symbol and number box height of Pd-vanilla?
Roman
On Oct 25, 2011, at 9:47 AM, Roman Haefeli wrote:
On Fri, 2011-10-21 at 18:36 -0400, Hans-Christoph Steiner wrote:
Pd vanilla still has different box sizes on different platforms, if I remember correctly, therefore the sizes will have to change somewhere.
I made a little test patch and took screenshots [1]. On three operating systems (Mac OS 10.6.4, Ubuntu 10.04, Windows 7) I tested Pd-extended-0.43.1 (from autobuilds) and Pd-0.43.1test4 (from Miller's site).
The results are contrary to what you are saying. For Pd-0.43.1test4 the box sizes are consistent across all tested platforms. For Pd-extended-0.43.1 the number, symbol, message and object boxes are 2 px less tall on Windows than on the other platforms. Due to this, only on Windows number and symbol boxes have the same height in Pd-vanilla and Pd-extended (though message and object boxes are 2px smaller in Pd-extended than in Pd-vanilla).
On the other two platforms, Ubuntu 10.04 and OS X, number and symbol boxes are 2 px taller in Pd-extended than in Pd-vanilla.
The hsliders, vsliders and cnvs have the exact same dimensions in every tested combination. Also is the width of number, symbol, message and object boxes consistent across all tested platforms and flavors.
Thanks for this, very useful. Guess I have some work to do. Could you add this report to the bug tracker? I check it out when I have time.
I tried to get these changes into vanilla, but I guess Miller didn't want them.
Currently, it looks like they are not necessary since the situation looks good for Pd-vanilla.
I've already spent a lot of time on it, so I've moved on since it works in Pd-extended. There should be a whole history of the discussion on pd-dev, i.e. the details of the issues. I don't remember them, I'm sure it was some annoying technical details.
Since only Pd-extended is not consistent across platforms, would that be reason enough to reconsider adapting Pd-extended to the symbol and number box height of Pd-vanilla?
Roman
I will fix it, but it needs to be compatible with previous Pd-extended releases since lots of GOPs have been tailored to that setup. Hopefully that's the same as Pd-vanilla 0.43.
.hc
----------------------------------------------------------------------------
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson
On Oct 25, 2011, at 9:47 AM, Roman Haefeli wrote:
On Fri, 2011-10-21 at 18:36 -0400, Hans-Christoph Steiner wrote:
Pd vanilla still has different box sizes on different platforms, if I remember correctly, therefore the sizes will have to change somewhere.
I made a little test patch and took screenshots [1]. On three operating systems (Mac OS 10.6.4, Ubuntu 10.04, Windows 7) I tested Pd-extended-0.43.1 (from autobuilds) and Pd-0.43.1test4 (from Miller's site).
The results are contrary to what you are saying. For Pd-0.43.1test4 the box sizes are consistent across all tested platforms. For Pd-extended-0.43.1 the number, symbol, message and object boxes are 2 px less tall on Windows than on the other platforms. Due to this, only on Windows number and symbol boxes have the same height in Pd-vanilla and Pd-extended (though message and object boxes are 2px smaller in Pd-extended than in Pd-vanilla).
On the other two platforms, Ubuntu 10.04 and OS X, number and symbol boxes are 2 px taller in Pd-extended than in Pd-vanilla.
The hsliders, vsliders and cnvs have the exact same dimensions in every tested combination. Also is the width of number, symbol, message and object boxes consistent across all tested platforms and flavors.
I tried to get these changes into vanilla, but I guess Miller didn't want them.
Currently, it looks like they are not necessary since the situation looks good for Pd-vanilla.
I've already spent a lot of time on it, so I've moved on since it works in Pd-extended. There should be a whole history of the discussion on pd-dev, i.e. the details of the issues. I don't remember them, I'm sure it was some annoying technical details.
Since only Pd-extended is not consistent across platforms, would that be reason enough to reconsider adapting Pd-extended to the symbol and number box height of Pd-vanilla?
Roman
Here's my contribution, a screenshot of Pd-extended 0.42.5 on Mac OS X 10.5.8, which matches the Pd-extended 0.43 Mac OS X and GNU/Linux screenshots. So time to fix Windows...
.hc
----------------------------------------------------------------------------
There is no way to peace, peace is the way. -A.J. Muste
On Oct 25, 2011, at 9:47 AM, Roman Haefeli wrote:
On Fri, 2011-10-21 at 18:36 -0400, Hans-Christoph Steiner wrote:
Pd vanilla still has different box sizes on different platforms, if I remember correctly, therefore the sizes will have to change somewhere.
I made a little test patch and took screenshots [1]. On three operating systems (Mac OS 10.6.4, Ubuntu 10.04, Windows 7) I tested Pd-extended-0.43.1 (from autobuilds) and Pd-0.43.1test4 (from Miller's site).
The results are contrary to what you are saying. For Pd-0.43.1test4 the box sizes are consistent across all tested platforms. For Pd-extended-0.43.1 the number, symbol, message and object boxes are 2 px less tall on Windows than on the other platforms. Due to this, only on Windows number and symbol boxes have the same height in Pd-vanilla and Pd-extended (though message and object boxes are 2px smaller in Pd-extended than in Pd-vanilla).
On the other two platforms, Ubuntu 10.04 and OS X, number and symbol boxes are 2 px taller in Pd-extended than in Pd-vanilla.
The hsliders, vsliders and cnvs have the exact same dimensions in every tested combination. Also is the width of number, symbol, message and object boxes consistent across all tested platforms and flavors.
I tried to get these changes into vanilla, but I guess Miller didn't want them.
Currently, it looks like they are not necessary since the situation looks good for Pd-vanilla.
I've already spent a lot of time on it, so I've moved on since it works in Pd-extended. There should be a whole history of the discussion on pd-dev, i.e. the details of the issues. I don't remember them, I'm sure it was some annoying technical details.
Since only Pd-extended is not consistent across platforms, would that be reason enough to reconsider adapting Pd-extended to the symbol and number box height of Pd-vanilla?
Roman
Ok, I think I fixed it, at least it worked on my Windows XP test VM. Basically, the code that was supposed to fit the font into the fixed box sizes was actually changing the box sizes. This commit now leaves the box sizes fixed so they are the same everywhere, then fits the font into the box.
http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pd-extended....
I'm guessing the different in Pd-vanilla comes from the different fonts that are in use, but it could be something else.
.hc
----------------------------------------------------------------------------
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
On Wed, 2011-10-26 at 01:15 -0400, Hans-Christoph Steiner wrote:
On Oct 25, 2011, at 9:47 AM, Roman Haefeli wrote: For
Pd-extended-0.43.1 the number, symbol, message and object boxes are 2 px less tall on Windows than on the other platforms.
Ok, I think I fixed it, at least it worked on my Windows XP test VM.
I can confirm that it is fixed. See attached PNG.
Roman
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 :/
cheers, _y
-- yvan.volochine@gmail.com http://yvanvolochine.com
-
Hans-Christoph Steiner -
Jonathan Wilkes -
Marvin Humphrey -
Miller Puckette -
Roman Haefeli -
yvan volochine