Everyone, this should not be a surprise
I'm unaware inlet/outlets grew... I'll have a look and see what's up. I don't think there's any reason for them to have chanced.
I spent *2 weeks* working on the GUI and there was extensive tweaking back and forth asking for feedback for a fews weeks afterwards both on this list and on Github:
https://lists.puredata.info/pipermail/pd-dev/2017-09/021272.html https://lists.puredata.info/pipermail/pd-dev/2017-09/021272.html
https://github.com/pure-data/pure-data/pull/227 https://github.com/pure-data/pure-data/pull/227
It's not like I / we suddenly pulled a "fast one."
Things move in steps. First was to fix a lot of the sizing issues as related to fonts, different platforms, and zooming. Part of porting in the extended sizing was that many people seemed to want it and, in the future, it would be much easier to allow for showing different inlet/outlet types. At least it would be an *option*.
A possible next step is to expose sizing and color options like this, but I only focused on fixes and laying the groundwork. As we can see, it doesn't;t seem to be possible to make *everyone* happy.
yeah, definitely looks very "extended-ish"
even if "uniform rendering across systems" is definitely a worthy goal, are the bigger inlets really unavoidable ?
Some people might as "are the inlets being a different size than the outlets really unavoidable?" :)
no chance to at least hack a personal version of a tcl file to make them thin again ?
Not yet. But it now *could* be a setting as the sizing was hardcoded before and now it relies on a single define. This define could now be more easily replaced by a variable.
(in fact the fat ones where a reason i intuitively rejected pdx/purrdata and stayed with vanilla. i just didn't like the bloated look. but here we are ...)
Really? Would you really *not* use Pd over this? For now, you can build Pd yourself and change the io height: https://github.com/pure-data/pure-data/blob/master/src/g_canvas.h#L47 https://github.com/pure-data/pure-data/blob/master/src/g_canvas.h#L47
"bloated?" Come on, it's like 1 pixel makes it look like MAX...
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
A followup, technical solution would be to add a second define, something like:
#define IO_INLET_HEIGHT 2 #define IO_OUTLET_HEIGHT 3
but that would depend upon if keeping the option for extended-style inlets matters. For what I could tell the last time around, the loudest voices wanted a consistent look and sizing across platforms.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
I didn't mean to suggest that you had pulled a fast one... in fact, I didn't see any difference in inlet-outlet sizes on linux and was wondering how teh size migth have changed on other OSes. (In fact, inlet/ outlet rendering had long been what I consider wrong on MacOS (white space in the middle of in/outlets) and from what I recall they're now filled in black, the way they are on the other platforms... so as far as I know the situation now is much better than before.
But now I'm curious to compare pre-0.47 and 0.47 on the three to see how inlet/outlet rendering actually changed, and perhaps to consider some way to control that. What seemed to me particularly interesting is the idea of alowing them to become bigger for people who have trouble seeing them... that sounds like a usability question that might be more important than mere aesthetics. But certainly the answer wouldn't be to revert to the very strange and buggy 0.46 behavior.
cheers Miller
On Fri, Mar 16, 2018 at 07:15:17PM +0100, Dan Wilcox wrote:
Everyone, this should not be a surprise
I'm unaware inlet/outlets grew... I'll have a look and see what's up. I don't think there's any reason for them to have chanced.
I spent *2 weeks* working on the GUI and there was extensive tweaking back and forth asking for feedback for a fews weeks afterwards both on this list and on Github:
https://lists.puredata.info/pipermail/pd-dev/2017-09/021272.html https://lists.puredata.info/pipermail/pd-dev/2017-09/021272.html
https://github.com/pure-data/pure-data/pull/227 https://github.com/pure-data/pure-data/pull/227
It's not like I / we suddenly pulled a "fast one."
Things move in steps. First was to fix a lot of the sizing issues as related to fonts, different platforms, and zooming. Part of porting in the extended sizing was that many people seemed to want it and, in the future, it would be much easier to allow for showing different inlet/outlet types. At least it would be an *option*.
A possible next step is to expose sizing and color options like this, but I only focused on fixes and laying the groundwork. As we can see, it doesn't;t seem to be possible to make *everyone* happy.
yeah, definitely looks very "extended-ish"
even if "uniform rendering across systems" is definitely a worthy goal, are the bigger inlets really unavoidable ?
Some people might as "are the inlets being a different size than the outlets really unavoidable?" :)
no chance to at least hack a personal version of a tcl file to make them thin again ?
Not yet. But it now *could* be a setting as the sizing was hardcoded before and now it relies on a single define. This define could now be more easily replaced by a variable.
(in fact the fat ones where a reason i intuitively rejected pdx/purrdata and stayed with vanilla. i just didn't like the bloated look. but here we are ...)
Really? Would you really *not* use Pd over this? For now, you can build Pd yourself and change the io height: https://github.com/pure-data/pure-data/blob/master/src/g_canvas.h#L47 https://github.com/pure-data/pure-data/blob/master/src/g_canvas.h#L47
"bloated?" Come on, it's like 1 pixel makes it look like MAX...
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
(Changing back to the right subject line).
Here's a technical peace offering, separate inlet & outlet height defines: https://github.com/pure-data/pure-data/pull/328 https://github.com/pure-data/pure-data/pull/328
In my mind, we could change these defines to canvas variables in the future ala x->gl_iheight, x->g_oheight, etc.
As far as I could tell, on my macOS system, inlets at 2 pixels high render fine without a white fill. I added a color fill for the 3 pixel height, otherwise the default white fill shows through. I think the object sizing might need to be adjusted more based on the height for more variability.
On Mar 16, 2018, at 7:25 PM, Miller Puckette msp@ucsd.edu wrote:
I didn't mean to suggest that you had pulled a fast one... in fact, I didn't see any difference in inlet-outlet sizes on linux and was wondering how teh size migth have changed on other OSes. (In fact, inlet/ outlet rendering had long been what I consider wrong on MacOS (white space in the middle of in/outlets) and from what I recall they're now filled in black, the way they are on the other platforms... so as far as I know the situation now is much better than before.
But now I'm curious to compare pre-0.47 and 0.47 on the three to see how inlet/outlet rendering actually changed, and perhaps to consider some way to control that. What seemed to me particularly interesting is the idea of alowing them to become bigger for people who have trouble seeing them... that sounds like a usability question that might be more important than mere aesthetics. But certainly the answer wouldn't be to revert to the very strange and buggy 0.46 behavior.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
-
Dan Wilcox -
Miller Puckette