Is there a reason why atoms and slightly shorter in height than object boxes, at least on macOS?
I'm not asking for the technical reason, as I know in the code why this is, but more the conceptual reason, or is it a bug?
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
I think there's only a very stupid, short-sighted reason: since numbers never have descenders, it wasn't necessary to add a pixel of whitespace underneath the rendered string. I was intent on reducing the size of everything to its absolute minimum.
I was forgetting about (or maybe not anticipating) "symbol" boxes - it's easy to make symbol box text collide with the box's outlet. And "|" characters can hit the bottom edge of the box even away from the outlet.
cheers Miller
On Sun, Sep 17, 2017 at 11:10:50PM +0200, Dan Wilcox wrote:
Is there a reason why atoms and slightly shorter in height than object boxes, at least on macOS?
I'm not asking for the technical reason, as I know in the code why this is, but more the conceptual reason, or is it a bug?
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
So it would be fine to use the same vert sizing as object boxes? I have that now in some testing and it looks good, especially for symbols. Maybe I'm too picky with the details :)
On Sep 18, 2017, at 12:12 AM, Miller Puckette msp@ucsd.edu wrote:
I think there's only a very stupid, short-sighted reason: since numbers never have descenders, it wasn't necessary to add a pixel of whitespace underneath the rendered string. I was intent on reducing the size of everything to its absolute minimum.
I was forgetting about (or maybe not anticipating) "symbol" boxes - it's easy to make symbol box text collide with the box's outlet. And "|" characters can hit the bottom edge of the box even away from the outlet.
cheers Miller
On Sun, Sep 17, 2017 at 11:10:50PM +0200, Dan Wilcox wrote:
Is there a reason why atoms and slightly shorter in height than object boxes, at least on macOS?
I'm not asking for the technical reason, as I know in the code why this is, but more the conceptual reason, or is it a bug?
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Just to add another data point of opinion: I would find symbol and number atoms with same size as message and object boxes visually more pleasing than the current smaller boxes.
Since Dan insinuated that he'll address "harmonization" of box sizes between platforms, please consider releasing those graphical changes in the same release, so that there will be only a single point in time where graphically elaborate patches break.
Thanks, Roman
On Mon, 2017-09-18 at 11:35 +0200, Dan Wilcox wrote:
So it would be fine to use the same vert sizing as object boxes? I have that now in some testing and it looks good, especially for symbols. Maybe I'm too picky with the details :)
On Sep 18, 2017, at 12:12 AM, Miller Puckette msp@ucsd.edu wrote:
I think there's only a very stupid, short-sighted reason: since numbers never have descenders, it wasn't necessary to add a pixel of whitespace underneath the rendered string. I was intent on reducing the size of everything to its absolute minimum.
I was forgetting about (or maybe not anticipating) "symbol" boxes - it's easy to make symbol box text collide with the box's outlet. And "|" characters can hit the bottom edge of the box even away from the outlet.
cheers Miller
On Sun, Sep 17, 2017 at 11:10:50PM +0200, Dan Wilcox wrote:
Is there a reason why atoms and slightly shorter in height than object boxes, at least on macOS?
I'm not asking for the technical reason, as I know in the code why this is, but more the conceptual reason, or is it a bug?
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
If you’re considering cleaning up things of this nature, then I’d add that outlets currently only extend two pixels into objects, messages, etc., whereas inlets extend 3 (and are therefore much easier to see). This is the case on macOS, at least.
If this was by design, then please ignore : )
Cheers, Kevin
On Sep 18, 2017, at 2:35 AM, Dan Wilcox danomatika@gmail.com wrote:
So it would be fine to use the same vert sizing as object boxes? I have that now in some testing and it looks good, especially for symbols. Maybe I'm too picky with the details :)
On Sep 18, 2017, at 12:12 AM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote:
I think there's only a very stupid, short-sighted reason: since numbers never have descenders, it wasn't necessary to add a pixel of whitespace underneath the rendered string. I was intent on reducing the size of everything to its absolute minimum.
I was forgetting about (or maybe not anticipating) "symbol" boxes - it's easy to make symbol box text collide with the box's outlet. And "|" characters can hit the bottom edge of the box even away from the outlet.
cheers Miller
On Sun, Sep 17, 2017 at 11:10:50PM +0200, Dan Wilcox wrote:
Is there a reason why atoms and slightly shorter in height than object boxes, at least on macOS?
I'm not asking for the technical reason, as I know in the code why this is, but more the conceptual reason, or is it a bug?
Dan Wilcox @danomatika <http://twitter.com/danomatika http://twitter.com/danomatika> danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/>
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
It's on the list. I have the sizing from extended mostly working which fixes the object & atom sizing issues we're seeing with 0.48.
On Sep 18, 2017, at 7:39 PM, Kevin Haywood khaywood@ucsd.edu wrote:
If you’re considering cleaning up things of this nature, then I’d add that outlets currently only extend two pixels into objects, messages, etc., whereas inlets extend 3 (and are therefore much easier to see). This is the case on macOS, at least.
If this was by design, then please ignore : )
Cheers, Kevin
On Sep 18, 2017, at 2:35 AM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
So it would be fine to use the same vert sizing as object boxes? I have that now in some testing and it looks good, especially for symbols. Maybe I'm too picky with the details :)
On Sep 18, 2017, at 12:12 AM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote:
I think there's only a very stupid, short-sighted reason: since numbers never have descenders, it wasn't necessary to add a pixel of whitespace underneath the rendered string. I was intent on reducing the size of everything to its absolute minimum.
I was forgetting about (or maybe not anticipating) "symbol" boxes - it's easy to make symbol box text collide with the box's outlet. And "|" characters can hit the bottom edge of the box even away from the outlet.
cheers Miller
On Sun, Sep 17, 2017 at 11:10:50PM +0200, Dan Wilcox wrote:
Is there a reason why atoms and slightly shorter in height than object boxes, at least on macOS?
I'm not asking for the technical reason, as I know in the code why this is, but more the conceptual reason, or is it a bug?
Dan Wilcox @danomatika <http://twitter.com/danomatika http://twitter.com/danomatika> danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/>
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Inlets&outlets are 2 pixels on linux and windows. It's a Tcl/Tk rendering inconsistency that makes inlets (if I remember correctly) appear as 3-pix-high rectangles with empty centers. Extended (which was primarily developed on a Mac) took this as the 'preferred' look and altered outlets to look like inlets (unlike the original design).
Which is better is a matter of judgement - but if inlets/outlets are grown to 3 pixel, then boxes should get another 2 pix of height. I'd suggest making this a "preference", perhaps selectable in the "font size" window.
cheers Miller
On Wed, Sep 20, 2017 at 03:23:49PM +0200, Dan Wilcox wrote:
It's on the list. I have the sizing from extended mostly working which fixes the object & atom sizing issues we're seeing with 0.48.
On Sep 18, 2017, at 7:39 PM, Kevin Haywood khaywood@ucsd.edu wrote:
If you’re considering cleaning up things of this nature, then I’d add that outlets currently only extend two pixels into objects, messages, etc., whereas inlets extend 3 (and are therefore much easier to see). This is the case on macOS, at least.
If this was by design, then please ignore : )
Cheers, Kevin
On Sep 18, 2017, at 2:35 AM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
So it would be fine to use the same vert sizing as object boxes? I have that now in some testing and it looks good, especially for symbols. Maybe I'm too picky with the details :)
On Sep 18, 2017, at 12:12 AM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote:
I think there's only a very stupid, short-sighted reason: since numbers never have descenders, it wasn't necessary to add a pixel of whitespace underneath the rendered string. I was intent on reducing the size of everything to its absolute minimum.
I was forgetting about (or maybe not anticipating) "symbol" boxes - it's easy to make symbol box text collide with the box's outlet. And "|" characters can hit the bottom edge of the box even away from the outlet.
cheers Miller
On Sun, Sep 17, 2017 at 11:10:50PM +0200, Dan Wilcox wrote:
Is there a reason why atoms and slightly shorter in height than object boxes, at least on macOS?
I'm not asking for the technical reason, as I know in the code why this is, but more the conceptual reason, or is it a bug?
Dan Wilcox @danomatika <http://twitter.com/danomatika http://twitter.com/danomatika> danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/>
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
I'm thinking of having, at the very least, a start flag to choose the extended styling ala "-style extended." This could be used as the basis for adding some sort of styling file parsing/loading, but that's beyond what I'm looking to do right now.
What I have now is the extended sizing, colors, etc working with Vanilla, largely using diffs from https://github.com/uliss/pure-data https://github.com/uliss/pure-data. I don't want to replace the traditional style, but there are some use cases for the extended styling such as the different rendering for audio & control inlets & outlets as well as the gray fill for atoms making their distinction from object boxes easy to see. I may move some of this to a different branch so we can look at things separately and I do not want to ignite some sort of styling war.
I will go back first and move just the object sizing stuff into a single commit first, then look into other styling stuff. I also have some IEM guis zoom things working as well, so this stuff in particular might be more suited to a bug fix release.
On Sep 20, 2017, at 6:46 PM, Miller Puckette msp@ucsd.edu wrote:
Inlets&outlets are 2 pixels on linux and windows. It's a Tcl/Tk rendering inconsistency that makes inlets (if I remember correctly) appear as 3-pix-high rectangles with empty centers. Extended (which was primarily developed on a Mac) took this as the 'preferred' look and altered outlets to look like inlets (unlike the original design).
Which is better is a matter of judgement - but if inlets/outlets are grown to 3 pixel, then boxes should get another 2 pix of height. I'd suggest making this a "preference", perhaps selectable in the "font size" window.
cheers Miller
On Wed, Sep 20, 2017 at 03:23:49PM +0200, Dan Wilcox wrote:
It's on the list. I have the sizing from extended mostly working which fixes the object & atom sizing issues we're seeing with 0.48.
On Sep 18, 2017, at 7:39 PM, Kevin Haywood khaywood@ucsd.edu wrote:
If you’re considering cleaning up things of this nature, then I’d add that outlets currently only extend two pixels into objects, messages, etc., whereas inlets extend 3 (and are therefore much easier to see). This is the case on macOS, at least.
If this was by design, then please ignore : )
Cheers, Kevin
On Sep 18, 2017, at 2:35 AM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
So it would be fine to use the same vert sizing as object boxes? I have that now in some testing and it looks good, especially for symbols. Maybe I'm too picky with the details :)
On Sep 18, 2017, at 12:12 AM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote:
I think there's only a very stupid, short-sighted reason: since numbers never have descenders, it wasn't necessary to add a pixel of whitespace underneath the rendered string. I was intent on reducing the size of everything to its absolute minimum.
I was forgetting about (or maybe not anticipating) "symbol" boxes - it's easy to make symbol box text collide with the box's outlet. And "|" characters can hit the bottom edge of the box even away from the outlet.
cheers Miller
On Sun, Sep 17, 2017 at 11:10:50PM +0200, Dan Wilcox wrote:
Is there a reason why atoms and slightly shorter in height than object boxes, at least on macOS?
I'm not asking for the technical reason, as I know in the code why this is, but more the conceptual reason, or is it a bug?
Dan Wilcox @danomatika <http://twitter.com/danomatika http://twitter.com/danomatika> danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/>
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On 2017-09-20 18:53, Dan Wilcox wrote:
I'm thinking of having, at the very least, a start flag to choose the extended styling ala "-style extended." This could be used as the basis for adding some sort of styling file parsing/loading, but that's beyond what I'm looking to do right now.
urgh!
so people are supposed building their GUIs to be pixel-by-pixel correct (because this seems to be what many here *want* to do), and then we have a flag to destroy their attempts? and when you hand out your patches, there's a README saying that "this patch must be opened with the '-style extended-is-the-new-legacy' to look correctly"?
honestly, i think a better option is to have people add a line to the README saying "this patch must be opened with Pd-extended-0.39 on OSX-10.5 to look correctly" and spend dev-time on more meaningful things.
an even better solution would be to have a consistent style that works on all platforms; even if that means breaking compat with older versions of Pd *and* with a project that has been dead for almost 5 years (and will stay dead). i see most of Dan's work in this light (my point is simply to not spend time on startup flags).
fgmasdr IOhannes
PS: being able to style (specific) patches in a CSS-like fashion (e.g. using GUI-plugins or whatever) would of course be ace.
Ah, so the 3-pixel inlets are an anomaly! I think that should be corrected to 2 pixels then - it seems too minor a detail to clutter up preferences with.
Kevin
On Sep 20, 2017, at 9:46 AM, Miller Puckette msp@ucsd.edu wrote:
Inlets&outlets are 2 pixels on linux and windows. It's a Tcl/Tk rendering inconsistency that makes inlets (if I remember correctly) appear as 3-pix-high rectangles with empty centers. Extended (which was primarily developed on a Mac) took this as the 'preferred' look and altered outlets to look like inlets (unlike the original design).
Which is better is a matter of judgement - but if inlets/outlets are grown to 3 pixel, then boxes should get another 2 pix of height. I'd suggest making this a "preference", perhaps selectable in the "font size" window.
cheers Miller
On Wed, Sep 20, 2017 at 03:23:49PM +0200, Dan Wilcox wrote:
It's on the list. I have the sizing from extended mostly working which fixes the object & atom sizing issues we're seeing with 0.48.
On Sep 18, 2017, at 7:39 PM, Kevin Haywood khaywood@ucsd.edu wrote:
If you’re considering cleaning up things of this nature, then I’d add that outlets currently only extend two pixels into objects, messages, etc., whereas inlets extend 3 (and are therefore much easier to see). This is the case on macOS, at least.
If this was by design, then please ignore : )
Cheers, Kevin
On Sep 18, 2017, at 2:35 AM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com<mailto:danomatika@gmail.com mailto:danomatika@gmail.com>> wrote:
So it would be fine to use the same vert sizing as object boxes? I have that now in some testing and it looks good, especially for symbols. Maybe I'm too picky with the details :)
On Sep 18, 2017, at 12:12 AM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu<mailto:msp@ucsd.edu mailto:msp@ucsd.edu>> wrote:
I think there's only a very stupid, short-sighted reason: since numbers never have descenders, it wasn't necessary to add a pixel of whitespace underneath the rendered string. I was intent on reducing the size of everything to its absolute minimum.
I was forgetting about (or maybe not anticipating) "symbol" boxes - it's easy to make symbol box text collide with the box's outlet. And "|" characters can hit the bottom edge of the box even away from the outlet.
cheers Miller
On Sun, Sep 17, 2017 at 11:10:50PM +0200, Dan Wilcox wrote:
Is there a reason why atoms and slightly shorter in height than object boxes, at least on macOS?
I'm not asking for the technical reason, as I know in the code why this is, but more the conceptual reason, or is it a bug?
Dan Wilcox @danomatika <http://twitter.com/danomatika http://twitter.com/danomatika <http://twitter.com/danomatika http://twitter.com/danomatika>> danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> <http://danomatika.com/ http://danomatika.com/<http://danomatika.com/ http://danomatika.com/>> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/> <http://robotcowboy.com/ http://robotcowboy.com/<http://robotcowboy.com/ http://robotcowboy.com/>>
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at <mailto:Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at> https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev <https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev>
Dan Wilcox @danomatika <http://twitter.com/danomatika http://twitter.com/danomatika> danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/>
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at <mailto:Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at> https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev <https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev>
Dan Wilcox @danomatika <http://twitter.com/danomatika http://twitter.com/danomatika> danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/>
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
It depends on your approach. Three pixels were used in extended and the forks using the extended styling as that's the minimum height to render a discernible rectangle border for the outline style of the control io versus the filled signal io.
On Sep 20, 2017, at 10:19 PM, Kevin Haywood khaywood@ucsd.edu wrote:
Ah, so the 3-pixel inlets are an anomaly! I think that should be corrected to 2 pixels then - it seems too minor a detail to clutter up preferences with.
Kevin
On Sep 20, 2017, at 9:46 AM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote:
Inlets&outlets are 2 pixels on linux and windows. It's a Tcl/Tk rendering inconsistency that makes inlets (if I remember correctly) appear as 3-pix-high rectangles with empty centers. Extended (which was primarily developed on a Mac) took this as the 'preferred' look and altered outlets to look like inlets (unlike the original design).
Which is better is a matter of judgement - but if inlets/outlets are grown to 3 pixel, then boxes should get another 2 pix of height. I'd suggest making this a "preference", perhaps selectable in the "font size" window.
cheers Miller
On Wed, Sep 20, 2017 at 03:23:49PM +0200, Dan Wilcox wrote:
It's on the list. I have the sizing from extended mostly working which fixes the object & atom sizing issues we're seeing with 0.48.
On Sep 18, 2017, at 7:39 PM, Kevin Haywood <khaywood@ucsd.edu mailto:khaywood@ucsd.edu> wrote:
If you’re considering cleaning up things of this nature, then I’d add that outlets currently only extend two pixels into objects, messages, etc., whereas inlets extend 3 (and are therefore much easier to see). This is the case on macOS, at least.
If this was by design, then please ignore : )
Cheers, Kevin
On Sep 18, 2017, at 2:35 AM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com<mailto:danomatika@gmail.com mailto:danomatika@gmail.com>> wrote:
So it would be fine to use the same vert sizing as object boxes? I have that now in some testing and it looks good, especially for symbols. Maybe I'm too picky with the details :)
On Sep 18, 2017, at 12:12 AM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu<mailto:msp@ucsd.edu mailto:msp@ucsd.edu>> wrote:
I think there's only a very stupid, short-sighted reason: since numbers never have descenders, it wasn't necessary to add a pixel of whitespace underneath the rendered string. I was intent on reducing the size of everything to its absolute minimum.
I was forgetting about (or maybe not anticipating) "symbol" boxes - it's easy to make symbol box text collide with the box's outlet. And "|" characters can hit the bottom edge of the box even away from the outlet.
cheers Miller
On Sun, Sep 17, 2017 at 11:10:50PM +0200, Dan Wilcox wrote: > Is there a reason why atoms and slightly shorter in height than object boxes, at least on macOS? > > I'm not asking for the technical reason, as I know in the code why this is, but more the conceptual reason, or is it a bug? > > -------- > Dan Wilcox > @danomatika <http://twitter.com/danomatika http://twitter.com/danomatika <http://twitter.com/danomatika http://twitter.com/danomatika>> > danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> <http://danomatika.com/ http://danomatika.com/<http://danomatika.com/ http://danomatika.com/>> > robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/> <http://robotcowboy.com/ http://robotcowboy.com/<http://robotcowboy.com/ http://robotcowboy.com/>> > > >
> _______________________________________________ > Pd-dev mailing list > Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at <mailto:Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at> > https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev <https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev>
Dan Wilcox @danomatika <http://twitter.com/danomatika http://twitter.com/danomatika> danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/>
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at <mailto:Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at> https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev <https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev>
Dan Wilcox @danomatika <http://twitter.com/danomatika http://twitter.com/danomatika> danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/>
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
-
Dan Wilcox -
IOhannes m zmoelnig -
Kevin Haywood -
Miller Puckette -
Roman Haefeli