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

Alexandre Torres Porres porres at gmail.com
Sat Nov 19 19:07:56 CET 2022

Em sex., 18 de nov. de 2022 às 18:27, Peter P. <peterparker at fastmail.com>

> is a toggle object an iemgui?


> 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

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 :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20221119/a30e14cc/attachment.htm>

More information about the Pd-list mailing list