plugdata-team
labels from iemguis should have a hardcoded font
Labels in vanilla's iemguis uses 3 specific fonts and in PlugData it seems that the font is specified globally and uses the font specified in 'themes'
so this can happen
And it really should not happen!
Why not just stick to the way the object behaves originally? The font is saved and preserved in the helo file of Pd. Please just stick to those 3 fonts.
If you want more fonts, I can make GUI objects in ELSE that take more options...
Why not just stick to the way the object behaves originally? The font is saved and preserved in the helo file of Pd. Please just stick to those 3 fonts.
This is a case where I choose to prefer a consistent experience within plugdata itself over consistency between plugdata and pd-vanilla. I agree it's not ideal, but using pd-vanilla's font for only some of the text would also look quite bad. I think it's best if labels (by default at least) follow the same font as text objects and comments. Otherwise it's gonna look like font salad.
Unless you have a better idea where we can have best of both worlds?
Unless you have a better idea where we can have best of both worlds?
I think this makes sense for regular Pd comments, and with those you cannot save/set the font anyway on the patch level. In fact, you can also change the font in Pd to whatever you like or have installed, and I believe they will impact everything, like number boxes, object boxes, message boxes, comments, etc...
So I guess this is the same idea after all?
Now, when it comes to labels, this is a more delicate situation, because we use GUIs to design User Interfaces, and describe what a button does and it's easy to pack things tightly in order to save space. Think of a GOP, and I can give you a good example, my [brane.m~] module that renders like a mess in PlugData because of that (and still suffers from other compatibility issues that will force me to find a better solution so it works well in both worlds!). The thins that you change the font indiscriminately it's easy to ruin and mess up everything in a GOP. So I'd refrain from doing that, specially because it also breaks a golden rule for me which is compatibility.
Unless you have a better idea where we can have best of both worlds?
I think this makes sense for regular Pd comments, and with those you cannot save/set the font anyway on the patch level. In fact, you can also change the font in Pd to whatever you like or have installed, and I believe they will impact everything, like number boxes, object boxes, message boxes, comments, etc...
So I guess this is the same idea after all?
Now, when it comes to labels, this is a more delicate situation, because we use GUIs to design User Interfaces, and describe what a button does and it's easy to pack things tightly in order to save space. Think of a GOP, and I can give you a good example, my [brane.m~] module that renders like a mess in PlugData because of that (and still suffers from other compatibility issues that will force me to find a better solution so it works well in both worlds!). The thins that you change the font indiscriminately it's easy to ruin and mess up everything in a GOP. So I'd refrain from doing that, specially because it also breaks a golden rule for me which is compatibility.
One thing I did to help with this, is that labels will (if needed) squeeze slightly so that they take up the same width as they would in pd-vanilla. Looking at [brane.m~], I think this is just slightly malfunctioning sometimes:
The problem isn't so much with the font, but rather with how it is spaced out, imo. And I think that's fixable!
I think you can also understand that offering 3 options, none of which are Inter, would be a strange decision if we consider plugdata in isolation.
I think this makes sense for regular Pd comments, and with those you cannot save/set the font anyway on the patch level. In fact, you can also change the font in Pd to whatever you like or have installed, and I believe they will impact everything, like number boxes, object boxes, message boxes, comments, etc...
So I guess this is the same idea after all?
Though I'm not sure it needs to be said, this is not how it actually goes in PlugData, as we can see from the screenshot above, the font only affects iemguis labels! And Ihave to bring this up as it goes in a different direction that you were aiming at, right?
And then I must say it really makes no sense to just affect iemguis labels and not the rest!
And also, [else/note] should really load and use the font it was saved with and set, but I haven't tested it.
I think this is just slightly malfunctioning sometimes:
It could be worse :) but it's still quite bad to me.
One thing we could maybe do, is replace Helvetica with Inter (because allowing the default font as one of the options is important too). Use that one as the default/init font for plugdata's labels. Then we could still have Menlo labels if you load a patch from pd-vanilla. And conversely, Helvetica is closer to Inter, so plugdata patches would also look better in pd-vanilla. I think that's reasonable?
I'd have to test that. I can't visualize it in my head as I haven't memorized font styles :) but I feel you're strongly attached to this for no good reason and I don't fully understand what you're proposing.
If Helvetica and Inter are close, why not leave Helvetica as an option? It doesn't seem to hurt and it doesn't break any golden compatibility rule for no good reason.
Also, the problem here is that changing the font changes the single option iemguis label currently have...
so what would it be now? Would you have a single version or the 3 of them but helvetica would be inter?
And if one changes the font, won't the problem still happen?
Anyway, going through all of what I investigated and checked and developing on it... here's the bottom line:
- The font settings could and should affect objects, messages, comments and what not (this is not happening and seems to go against your idea). A 'Vanilla theme', by the way, would require 'Dejavu Sans Mono' or 'Menlo' as the front for comments and everything else. So this also relates to https://github.com/plugdata-team/plugdata/issues/1656
- iemguis should stick to their original settings and those different fonts could be chosen and respected
- I guess you can make the default value of iemnguis 'helvetica', it's not a big issue to change default values, and, well, that's close to the default font type of plugdata
- other GUIs, like [else/note] should also stick to the set font (haven't checked that yet)
- I said I could offer alternatives in ELSE for other GUIs that behave differently and I do have plans to offer alternatives for basically all GUIs in Vanilla, but my idea is to not offer the silly label option and just leave that job to [else/note], so maybe we can think of a way to work it out and have it load the default font or something and just leave iemguis alone?
I think wanting to use the same font everywhere inside an app isn't a "strong attachment for no reason". This is really common sense for UI design (google "should I use a single font for my app"). If you don't use the same default font everywhere (or at least allow the user to do that), it's gonna look messy. And in this case it's worse because it would be the only thing on canvas with a different font, it will definitely stick out in a bad way.
Compatibility is important, but I'm not going to force all users to use a font for labels that will look out of place in plugdata. We could try replacing one of the fonts, but Inter has to be one of the options.
the 3 of them but helvetica would be inter
Yes, that is the idea. At least we're swapping 2 sans-serif fonts this way, instead of a monospace font.
And if one changes the font, won't the problem still happen?
Well, only if you pick Helvetica. But then you get a font that's at least more similar to Helvetica than Menlo is. So that's still a nice improvement.
Regarding compatibility as a golden rule: not if it worsens the experience for everyone who doesn't care about that. Making sure vanilla patches are usable is important. But I'm not gonna make plugdata-made patches look worse for backward compatibility.
I'm not sure I get what you mean yet... maybe we can chat over it so things get straightened out and I get it...
Though I'm afraid I may have to test and see for my self...
As for that being a bad design choice, I agree... I do think that iemguis is a curse, the label thing for all of them was the worst of all I guess... it's not a surprise I feel like offering alternatives for ALL iemGUIs, they suck too much, and Miller should not have taken them, and I know he regrets it, but hey, he didn't have the time and just took what Thomas did... and the way it forced a font setting, and those 3 ones of all, was also a terrible idea and I agree...
But as it is... it defaults to the actual font Pd uses... so... there is not a real problem in the source. People get by default the same font that Pd uses as a default font, so nothing weird actually happens... it does actually follow this rule of using a single font for the app.... at least by default...
The problem here is that you do offer a different font, so you're the one changing things and and you have overlooked this adaptation problem... which breaks compatibility.
I guess you can better adapt this and make iemguis load whatever font you have from the theme, and make it change, and have it as an extra feature, something that will work for PlugData, and it would just restore to the default font in Vanilla... I don't know, I have to better think.
But not being able to reproduce the same font and settings from Vanilla into PlugData is a very complicated problem that we could just avoid for the sake of it.
Now, one option is to 'deprecate' something and offer a better alternative, and document it all...
That is to say that iemguis is what it is and that it's bad, and that we offer other alternatives with [else/note] and other GUIs we can design...
For instance, no one is having problems with labels in [knob] and [numbox~] and [function] and etc :)
[else/note] should really load and use the font it was saved with and set, but I haven't tested it.
For the record, I tested it, and yeah, it loads the font it was saved with, and to me the same should apply for iemguis of course.
I also see that the default font for [note] is inter, and that's cool
I aoso see that changing the theme font does not interfere with the default font in else/note... and maybe it should, unlike iemguis' labels