Currently font size on nsliders is static, so even if you make an abnormally large one, the text never changes.
I feel like it would make sense for nsliders font sizes to scale in the same way and at the same rate as buttons. For example, if a button and nslider have identical size() and contain the same text, they font sizes should be the same.
Here’s another classic thread for you Rory… any thoughts about how this could work, if at all? Should the text always scale, never scale, optionally scale?
I think worst case scenario, maybe I could work around it with a label widget acting as the display, and an invisible nslider over it? Not ideal… but it’s not something I’d be using widely.
We just need to decide if the text should auto-scale, or if we just set it with explicitly? Allowing users to change it explicitly gives the most scope.
I agree, but text for label’s font size is automatically decided my the widget height. So I feel like if nslider has a way to manually set that, labels probably should too?
Maybe font size is set by height, but can be overridden manually with something like fontsize() or textsize()?
The only thing with allowing it to scale with size is that it may potentially change how older instruments look. But then again, I can’t really imagine to many people were creating very large number boxes, with very small text in them…
Maybe default to the old behavior, and allow a simple override such as scaletext(1)? Honestly, I’d be fine with any of the proposed solutions, and also agree that not messing up too much on existing instruments is an important consideration.
I went ahead and committed some code that will auto-scale. Some users might notice a little difference in their GUIs, but I don’t think it’s enough to really upset anyone! One can override using the fontsize() identifier.
Hrm, I’m using yesterdays build and wasn’t able to get fontsize() to affect the nslider…
I didn’t think today’s build was required since the only change that’s listed is the bumped version number, but I’ll give it a shot as well in a little bit.
I guess I shouldn’t trust the description on the azure page then? I was just going off that 
Or perhaps I was just looking in the wrong place…
Either way, I’ll grab the new build now and see if I can get it to work.
Azure builds the latest commit, which was a version bump. The commit before that was the updated number box.
Oh I see, my mistake. Guess I’ve gotten rusty on staying current 
I grabbed the new version and everything seems to be working as expected.
Thanks again, Rory!
Hello, everyone! I’m trying to find the “commit” talked about in this thread, as I had the same issue with number boxes, but I can’t seem to find it. I recently downloaded version 2.3.0, which, I guess, should have the fontsize option for nslider. I’m working on OS X 10.12.6 (High Sierra). Is there something I’m doing wrong?
Never mind! I found the Azure builds page. 
All is well, hehehe. Thanks, anyway.
Hey Rory,
I haven’t isolated a “pure” test for it yet, but it seems like fontsize() isn’t working for nsliders that are imported, only for ones that are native to the instrument.
Does this seem likely, or should I try to trim down a more clean test example?
Looks like you’re right 
Cool, glad I’m not imagining it. Not a big rush, but something I noticed. Thanks!
I just pushed a fix through. Take a look at the Azure builds, it should be cooked in about half an hour
