That’s of course true. So it could move around in text mode and stay centered in edit mode.
Not if you provide an API to access font sizes for example for the chosen node size. (I know this in particular is currently possible, but not very convenient at all, it’s so cumbersome to implement, that I usually just don’t). Apple provides dynamic type (font sizes, probably better in iOS, but still.) Maybe the fontSizes could be tied as multiples to systemFontSize
I wonder since long if that is about to come, it would save so much mouse action if there’d be a shortcut to make the info box (one or another text field there) the active responder. Maybe always activate the last used text field.
MacOS doesn’t have dynamic font sizes. systemFontSize always returns 13.
There is a GSHandleSize defaults setting can be changed in the Preferences. I had the info box respond to it, too. But I changed it that the info box is always “big” now.
Oh, I see. Stupid Apple. I still think it would be handy to implement some sort of global font size(s) that developers can jump on instead of using all sorts of arbitrary sizes. I’m guilty of that all the time spending hours changing sizes back and forth and fearing that those are either too big or too small anyway. If there’d be some dynamic sizes in the user preferences, I guess developers are happy to use those too.
1 Like
Fully onboard with this. The user experience of some plugins with small type is not great. It’s just too hard to read and distracts the workflow.
An app specific font size scalar to base the plugins on that helps towards a more visual consistent UI/UX is great. 
1 Like