[PD] some gui objects with grey background in help patches?

José de Abreu abreubacelar at gmail.com
Sun Nov 20 19:07:36 CET 2022

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:
1. 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 at gmail.com> escreveu:

> Em sex., 18 de nov. de 2022 às 18:27, Peter P. <peterparker at 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20221120/5e99ff45/attachment-0001.htm>

More information about the Pd-list mailing list