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

Alexandre Torres Porres porres at gmail.com
Tue Nov 22 01:37:27 CET 2022


Em seg., 21 de nov. de 2022 às 02:44, Peter P. <peterparker at fastmail.com>
escreveu:

> I think a change back to no colors


There's no "change back to no colors" :) Let me emphasize *I did
include* iemguis
when appropriate. Before that, bangs/toggles were exceptionally used on a
couple occasions. You’d have "bang" messages and “1”/“0” instead. No
sliders ever! Now I also use a toggle into a "pd dsp $1" message instead of
using two messages to turn dsp on/off, many times, this is all we have as
"colored examples". This discussion is giving the false impression that
iemguis are all over the place, that is not true! It's also giving the
impression it was always like that, but before this last change, you'd
rarely find iemguis at all.


I know this isn't really important, but I think it's funny hearing
something like “*I liked it better when bangs and toggles had no colors in
the help files, please change back to the way it was*” because… well… that
didn’t really exist :) that is a false memory, but that's it, it's just
something funny...


should be considered.
>

Furtherly changing it to white is something certainly possible to consider,
but you gotta make a case.


Em seg., 21 de nov. de 2022 às 02:57, Scott R. Looney <
scottrlooney at gmail.com> escreveu:

> modifying all vanilla help file backgrounds for a few power users used to
> stark UI design, there would have to be a lot of strong support for that
>

Yes, there'd need to be support for that, but that would also be a silly
issue to pursue. It's not the real problem that was raised here though,
which was "*colors may confuse **students*", and the underlying implication
issue is that teachers would then have hard times managing the class with
such doubts by having to explain to students they can set colors and stuff.
That's it!


I tried my best to argue that I don’t see it as something to actually worry
about based on my own experience and history of teaching Pd for 15 years to
hundreds of people (using Pd extended and help files from externals that
have different templates). I can't remember anyone ever asking or getting
confused. If it happened, it seems it was rare and I wasn't bothered to
spend a few seconds explaining it so it didn't stick in my memory. I can’t
really see how disruptive this can be, didactically. Worst case scenario,
if that actually happens (since we don't even have a real life example of
this ever happening) just give simple, quick and basic information.


It's not the first time I said this, and the fact that Extended and other
externals have a different template was a strong key point in my last
argument, but I feel it was conveniently ignored.



> I'm designing a tutorial that I use to teach for about 15
> > years and it depended on Pd Extended for over a decade. Now it

> depends on ELSE which has a more discrete template design.

> I never saw anyone being confused by the complexity, colorfulness

> or whatever... on the contrary!

All fine, I was only raising this topic for Vanilla, not wrt. to the
> valuable contributions you mention.
>

See? My whole main point of discussion was ignored as if it didn't make
sense in this discussion... I wonder if you got it.

I always found Pd-Extended to be overloaded and a bit bloated. The
> reasons why Pd has a simple and "pure" design are stated by Miller in
> several of his publications. One of the reasons was to keep the code
> managable. If I remember correctly, the complexity of Extended was also
> what brought it down in the end when Hans coulnd't keep up with the
> workload.
>

Now, I consider this doesn't make sense indeed, as it misses the point
completely. We're not discussing code base maintainability. It's not like
what I did threatens Vanilla's development... I can say I am handling this
and that's one of the many digressions I've seen that missed my points.

> Pd extended is gone but I'm still not sure we've fully got over it

Yes we are over it, because we have the Deken package manager.


Sorry, I don't think you're listening at all :) I think it's given that I
know deken, right?

No, we're not over it. People still miss it, people still use it. I said it
and it also got ignored: there are several tutorials out there that are
based on Pd-extended and many teachers, to this day, feel it's just easier
for newbies and students to use either extended or the Pd-l2ork/Purr Data
alternative, whose main selling point is exactly this! I often hear
teachers choose it cause it's "easier", "better documented" and compatible
with some tutorials (even though it has that green toggle in the help file
of [float]). Do you have data against this? Is Pd-l2ork/Purr Data not a
thing? Of course this happens even though we have deken (needless to say).
It seems you're just denying things I say without taking into consideration
what I really said - then I have to repeat my point and it gets tiresome.

Please don't take a poll on Facebook as a consensus either. I suspect

that users there might have a different profile than mailing list users
> even.


So I may have to ignore another valid point of mine because of a different
user profile on facebook. I then presume you think mail list users are of a
special class, not just "users". Like, we do code, we teach, we have a
better sense of software development and stuff than facebook people. Not
really true as previously noted, but I don't know, it sounds way too
elitist thinking to me. Moreover, your whole point was how this is
reflected on real life users, students, enthusiasts, newbies and etc. I see
a conflict here. Do you want to speak on their behalf and not listen to
them?


If we have less developers over there or whatever, if anything, we might
have to listen to them more! Now, I'm a fellow
teacher/developer/collaborator, did you listen to my points? Did you get
them? Again, I felt ignored.


Not actually thinking about the user base, what they really want, and
making decisions on their behalf is a common problem that I see, by the
way. I, for one, do care and think a lot about it. When presenting my
argument I also based on requests from users I've seen over the years.


Sorry, but I'll take into consideration the facebook poll. So far, there
are 18 positive votes for gray iemguis, 1 saying we could have yet more
colors and complexity and 1 negative vote (from another person that was
also in this mail list discussion). If I count you both, it's about 10%
saying colors are problematic against 90% - and it becomes 6% negative
votes if we also count indiferent votes.

I see your point, how you think adding complexity might confuse students. I
think we even agree to some extent, but you're not adding real information.
As I see it, it's only an assumption so far, with no real life example of
this actually even happening yet. So I stick to my first impression: sorry,
I don't buy it. I also don't see you acknowledging my arguments or properly
responding to them.


I'll also extend to the other comment here, that copying colored iemguis
from help files could be harder for students. It would be good to have real
life examples of this ever happening to back this up. Has any of this ever
happened? If not, ideally at least a specific case where this has such
potential. Again, the majority of help files don't even have iemguis. Some
only have a toggle into "pd dsp $1", so how much is this a real potential
issue?


How often do people even copy examples instead of just using them to check
information? If they copy, who says that they're gonna use an iemgui bang
to trigger the object instead of a bang coming from a [trigger] object? I
know the documentation pretty well, that aren't that much really "complex"
or "day to day usage examples" full of iemguis on them. Have a look, prove
me wrong. Which would be the most copied "examples" from the help files and
how many do have iemguis all over the place?


Also, is there any data supporting how people prefer to copy white iemguis
instead of whatever other color? How do Extended or Purr Data users deal
with it? Has anyone ever complained? What about people that use external
libraries in Vanilla like ELSE, Cyclone, mrpeach and others, do they suffer
from this? Do we have a single complaint like countless complaints I heard
that vanilla's documentation wasn't that nice over the years?


If we don't have objective points to make a case, isn't this just
bikeshedding? Before any change really happens, there should be a stronger
case than something like "I am assuming people may not like it" or "I might
have students who get confused and I wouldn't like to explain it to them".
Feels like a weak case to me.

I still think the real issue could just be some personal aesthetical
annoyance, which I don't is invalid in any way, but we need to have more
people saying they don't like this instead of people saying they do...


Em seg., 21 de nov. de 2022 às 10:41, Dan Wilcox <danomatika at gmail.com>
escreveu:

> 1. Alex did *alot* of work (re)structuring *all* of the help files. Thank
> for that work, Alex.
>

welcome ;)


> I can think of numerous changes I have made/proposed where I was frankly
> annoyed by the negative feedback
>

:)


> but, after stepping back and looking again, realized that I didn't really
> care too much about it either way and either changed it back or made an
> improvement that was different than the original approach.
>

I could change it as I wouldn't like forcing something that has a strong
rejection, but I'm not getting convinced that's the case... I can't see
what else to do instead either...


> after a certain point, endless discussions about how things "should be" or
> what constitutes "consistency" is relatively moot (...) if this issue is as
> big as it appears to be, please, clone the GitHub repo, change all of the
> GUI objects in the help patches back to white, then submit a PR. The
> details of the technical discussion can continue there, I think.
>

Yeah, I think this one reached that counterproductive point. Let's see what
else happens, if more people start complaining or whatever, cause, as it
is, I ain't doing it :) Anyone can go ahead and do a PR and further
discussion can happen there. It should be clear I don't call the shots and
have no final decision, but I would wait or build a better case before
filing such a PR ;)

Cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20221121/945c9ff4/attachment-0001.htm>


More information about the Pd-list mailing list