Hello all, ok, some thoughts about the topic.
I think it would be nice to have colors with meaningful information, we currently don't have those, indeed just a grey color background doesn't transport any information, it is just an aesthetic decision, as porres stated. As it is, it doesn't make much difference if we have them or not... and as the discussion is going on here, people seem to prefer without them
So going in the opposite direction, how could we add information with the colors? I propose this:
When viewing a helpfile all numberboxes, list atoms, toggles, bangs etc are there to fulfill two basic tasks:
- input something to an object, so we are supposed to interact with those
guis to learn how an object behaves 2. get output from that object, so we have visual feedback to what each object returns when receive some arguments or inputs
So from the start, we could have two different classes of colors that could emphasize where to look to get specific information, guis meant to be used to interact with the object and guis to look for its output. If this is done in a coherent way, we could even add more colors to differentiate different types of inputs/outputs.
For example, a correct and expected input could receive one color, a bad case would receive another color to show an example of what could go wrong. If the object could output an error (as a visual bang for example), this type of output could have some "warning" color... we could think and discuss if this makes any sense, and which cases could benefit from it, but colors with meaningful information could be interesting.
Some random pros and cons, in my opinion:
I think that inducing curiosity about gui enhancement is good for newcomers. If people never discover that guis can change the properties, they will never search on how to do those. Ok, if I go to put menu, the color is one, but if I go to this helpfile the color is another. Hmm! interesting, they can change colors... but how? let me search on the internet / manual / helpfiles / ask my mentor in this course. This leads to learning, and they could even discover more on their own or ask in forums or other places with the community.
On the other hand, I understand that too many colors would make the opposite effect, it could make the patches hard to look if not used properly, and if in the future pd receives color themes, hardcoded colors would disturb people that choose one theme, and then when going to a helpfile get an unreadable color or very contrasting one with their theme... So maintaining such a thing would be harder, we would need to fit a default color palette for those things, and then the user with a custom theme would have more colors to change in their settings...
But at the same time, in this hypothetical scenario of a pd with color themes, having default palette colors would make easier to disable all colors, so people that hate colors in their helpfiles could just disable them and be happy xD
For people that copy paste the helpfiles into their patches, I think that the matter depends. Using an external as example, on [mrpeach/udpsend] helpfile there is a green colored toggle with a label "connected" after it. When I was learning this object, the green color or the label never bothered me, instead, I knew that this was coming from the helpfile and was nice as a default descriptive toggle. And if you have some specific look in mind, you would need to change the colors anyway... or create all the guis from start by yourself xD
Em sáb., 19 de nov. de 2022 às 15:10, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em sex., 18 de nov. de 2022 às 18:27, Peter P. peterparker@fastmail.com escreveu:
is a toggle object an iemgui?
yes.
why should all iemgui's within one help patch be gray, and number boexes, or the new graphical "symbol" object remain black-and-white?
I don't know what you mean by *new graphical "symbol" object* there is no "new" one. GUI boxes (number, symbol and list boxes [this one new]) cannot set the background color, at least not yet (there are plans to add background colors to them and I agree they could follow the help file's standard then).
It's rather the inconsistency within the vanilla help patches for internal objects, and the objects that I create from the "Put" menu.
Then it's a whole different story. You first specifically mentioned it was help files, and I quote you: "*there is many help patches with these default colors*". Anyway, I'm glad there is no real inconsistency to other help files then.
What are users expected to learn from this visual difference in the help patches, what does the color difference signify? To me personally, the color does not transport any meaningful information and this why I perceive it as a distraction rather than a feature.
The color wasn't really supposed to "transport any *meaningful information*" indeed, whatever that should mean. And it seems to me a rather "meaningless" philosophical discussion to argue about the "meaning" and "signification" of background colors :) it is not the point. Just like *life* itself, it has no meaning ;)
I also don't think the point is for them to "learn" something, but if newbies are confused to see something with a different color than what they get from the Put menu, maybe it's good that they learn that these things can change color and not be completely thrown off and confused by it.
I say this because your point now seems to be that people may get distracted and confused by the fact these things can change color. I see your point, but I don't think you can speak for others. And you also seem to know these things can change colors so that may not be your real problem. Anyway, patches with colored iemguis are quite common. The help file of toggles and other iemguis also abuse the use of different color settings and other appearance goodies for didactical purposes right to the front...
So, even though you completely changed your point, I don't buy your new 'inconsistency' issue. I can't see any other meaningful discussion than an aesthetical one. If you read the issue I opened when I proposed this new standard, I discussed about it. I said I liked the sheer simplicity of help patches, that we shouldn't make it too fancy or even colorful, but that I would like to use more iemguis in the help files and that they could at least be 'light gray'. I also said I use this standard in the help files of Cyclone and ELSE, just because I think "*it looks good*"... That's it... and no Cyclone or ELSE user has ever complained to me why a slider in the help file was light gray instead of the default white...
I don't think there's nothing to talk about it here other than the real point of having a colored iemguis: it is purely an aesthetical decision. Problems one may or may not have are simply completely subjective and merely in regards to aesthetics as I see it.
It could have been any other new standard format for help files, with 'fancy' things all over the place, with different red and yellow colors, many canvases in the background that are purple, colored labels with different fonts, different sizes and colors as well, with drawings made of ASCII art, whatever, just because one thinks it's "nice". Not everyone agrees, so others might like it as well and others don't... But I just went for a really, really, really minor and discrete thing :)
cheers _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list