Howdy all,
without reading too far into this...
Alex did *alot* of work (re)structuring *all* of the help files. Thank for that work, Alex.
Sometimes people wonder why Pd doesn't change in leaps and bounds. This is one reason: no matter how big or small a change may be, there is always someone with a (valid) reason to *not* want the change. Even for end cases.
If the change is as much of as issue that it requires custom scripting or startup flags to address it for some, maybe it's worth considering an additional update to seriously address the issue? Stepping back, is the proposed change to fix the issue that much of a major issue in itself? Worth looking into?
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 believe I've brought this up on the list before, but after a certain point, endless discussions about how things "should be" or what constitutes "consistency" is relatively moot. In the end, it comes down to writing code / making changes and getting those changes into the codebase, however this is done.
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.
Don't get me wrong, I am not implying that bringing up an issue is not valid, but really after a certain point of back and forth, things could move forward concretely IMO. :)
On Nov 21, 2022, at 12:00 PM, pd-list-request@lists.iem.at wrote:
Message: 1 Date: Mon, 21 Nov 2022 10:05:57 +0100 From: "Peter P." <peterparker@fastmail.com mailto:peterparker@fastmail.com> To: pd-list@lists.iem.at mailto:pd-list@lists.iem.at Subject: Re: [PD] some gui objects with grey background in help patches? Message-ID: <20221121090557.pxsmirhxjxhwnqpb@fastmail.com mailto:20221121090557.pxsmirhxjxhwnqpb@fastmail.com> Content-Type: text/plain; charset=us-ascii
Hi Scott,
- Scott R. Looney <scottrlooney@gmail.com mailto:scottrlooney@gmail.com> [2022-11-21 06:56]:
[...]
i guess there might be considered a Tcl/Tk option to not have/draw colored backgrounds in any patch window, similar to how one can change the default canvas background/foreground color currently.
I don't think this is a good solution. We definitely do not want more options/startup flags.
but as for 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.
I guess it can be done with a script and wouldn't need to be done manually.
additionally the comment on Facebook users being considered less 'hardcore' is somewhat prejudicial. there is quite a lot of crossover on FB with mailing list users.
Thank you for that point.
you should also consider putting this survey on the Discord that Mike(Miguel) Moreno runs as a number of users there are also on the mailing list.
Yes, or even here: https://framadate.org/create_poll.php?type=autre&lang=en https://framadate.org/create_poll.php?type=autre&lang=en where no accounts are required.
best, P
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
I wanted to add my voice here to say that I like the work Alex did and appreciate the many many bug fixes, clarifications, the drive for consistency and readability across the help patches. Alex dedicated a significant time to this and in my view the result is convincing and a clear improvement. I acknowledge that purists may be offended but on the other hand they can keep using Pd 0.49 if they like things to stay as they were. I think Dan is right with his conclusion.
Max
On 21.11.22 14:41, Dan Wilcox wrote:
Howdy all,
without reading too far into this...
- Alex did *alot* of work (re)structuring *all* of the help files.
Thank for that work, Alex.
- Sometimes people wonder why Pd doesn't change in leaps and bounds.
This is one reason: no matter how big or small a change may be, there is always someone with a (valid) reason to *not* want the change. Even for end cases.
- If the change is as much of as issue that it requires custom
scripting or startup flags to address it for some, maybe it's worth considering an additional update to seriously address the issue? Stepping back, is the proposed change to fix the issue that much of a major issue in itself? Worth looking into?
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 believe I've brought this up on the list before, but after a
certain point, endless discussions about how things "should be" or what constitutes "consistency" is relatively moot. In the end, it comes down to writing code / making changes and getting those changes into the codebase, however this is done.
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.
Don't get me wrong, I am not implying that bringing up an issue is not valid, but really after a certain point of back and forth, things could move forward concretely IMO. :)
On Nov 21, 2022, at 12:00 PM, pd-list-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
Message: 1 Date: Mon, 21 Nov 2022 10:05:57 +0100 From: "Peter P." <peterparker@fastmail.com mailto:peterparker@fastmail.com> To:pd-list@lists.iem.at mailto:pd-list@lists.iem.at Subject: Re: [PD] some gui objects with grey background in help patches? Message-ID: <20221121090557.pxsmirhxjxhwnqpb@fastmail.com mailto:20221121090557.pxsmirhxjxhwnqpb@fastmail.com> Content-Type: text/plain; charset=us-ascii
Hi Scott,
- Scott R. Looney <scottrlooney@gmail.com
mailto:scottrlooney@gmail.com> [2022-11-21 06:56]: [...]
i guess there might be considered a Tcl/Tk option to not have/draw colored backgrounds in any patch window, similar to how one can change the default canvas background/foreground color currently.
I don't think this is a good solution. We definitely do not want more options/startup flags.
but as for 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.
I guess it can be done with a script and wouldn't need to be done manually.
additionally the comment on Facebook users being considered less 'hardcore' is somewhat prejudicial. there is quite a lot of crossover on FB with mailing list users.
Thank you for that point.
you should also consider putting this survey on the Discord that Mike(Miguel) Moreno runs as a number of users there are also on the mailing list.
Yes, or even here: https://framadate.org/create_poll.php?type=autre&lang=en https://framadate.org/create_poll.php?type=autre&lang=en where no accounts are required.
best, P
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Tue, 2022-11-22 at 13:32 +0100, Max wrote:
I wanted to add my voice here to say that I like the work Alex did and appreciate the many many bug fixes, clarifications, the drive for consistency and readability across the help patches.
I agree with Max and Dan here. I appreciate the work done by Alex and I think it's a clear improvement. On the specific issue of colors, I'm indifferent. However, he's the one who did the work and who had to decide on many little things. It's in the nature of such proceedings that not everyone agrees on the every last detail. My impression is opinions on the color issue are mixed and not clear-cut, thus I doubt time on making everything black-white again is well spent.
Roman
I agree with Max and Dan here. I appreciate the work done by Alex and I think it's a clear improvement. On the specific issue of colors, I'm indifferent.
+1
My impression is opinions on the color issue are mixed and not clear-cut, thus I doubt time on making everything black-white again is well spent.
It takes a single GREP to turn them all back to black-white.
I can do a PR to Alex's branch if needed.
Can we switch the discussion back to "How colors should be handled in Pd's documentation" and sort this out?
Lucarda
--
Mensaje telepatico asistido por maquinas.
On 22/11/2022 09:56, Roman Haefeli wrote:
On Tue, 2022-11-22 at 13:32 +0100, Max wrote:
I wanted to add my voice here to say that I like the work Alex did and appreciate the many many bug fixes, clarifications, the drive for consistency and readability across the help patches.
I agree with Max and Dan here. I appreciate the work done by Alex and I think it's a clear improvement. On the specific issue of colors, I'm indifferent. However, he's the one who did the work and who had to decide on many little things. It's in the nature of such proceedings that not everyone agrees on the every last detail. My impression is opinions on the color issue are mixed and not clear-cut, thus I doubt time on making everything black-white again is well spent.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
- Lucas Cordiviola lucarda27@hotmail.com [2022-11-22 15:47]:
[...]
Can we switch the discussion back to "How colors should be handled in Pd's documentation" and sort this out?
Thank you Lucarda! Can this be discussed here, or would github be a more suitable place?
cheersz, P
Don't know, I prefer here.
I'm not a pedagogue but if you all agree that this is better for learning I think you got a point.
Or if there are other tcl/tk (or future gui) benefits in just using defaults colors there is another point. (not sure about this one)
Or whatever other point that can came about sticking to black-white.
--
Mensaje telepatico asistido por maquinas.
On 22/11/2022 13:23, Peter P. wrote:
- Lucas Cordiviola lucarda27@hotmail.com [2022-11-22 15:47]:
[...]
Can we switch the discussion back to "How colors should be handled in Pd's documentation" and sort this out?
Thank you Lucarda! Can this be discussed here, or would github be a more suitable place?
cheersz, P
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I am putting up a proposal about using colors in vanilla the help patches for discussion. I think these patches should
- Emphasize and encourage users to use the color features of GUI elements by showing that in their respective help patches.
- Use colors in vanilla help patches to highlight essential objects and actions, for example to indicate the one single bang button I need to press to start an example therein.
- Stick to the non-color versions otherwise when no highlighting is necessary, as for example the toggles for loudspeaker channels in testtone.pd
Looking forward to a fruitful discussion, P
Ok, this can be discussed and improved.
So now the issue is just about some *extra* grey stuff?
(but you can live with it, right?)
--
Mensaje telepatico asistido por maquinas.
On 22/11/2022 16:15, Peter P. wrote:
I am putting up a proposal about using colors in vanilla the help patches for discussion. I think these patches should
- Emphasize and encourage users to use the color features of GUI elements by showing that in their respective help patches.
- Use colors in vanilla help patches to highlight essential objects and actions, for example to indicate the one single bang button I need to press to start an example therein.
- Stick to the non-color versions otherwise when no highlighting is necessary, as for example the toggles for loudspeaker channels in testtone.pd
Looking forward to a fruitful discussion, P
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Dear Lucas, list,
I am looking forward to get a discussion going, but for this we need more views from others. I would indeed see an improvement to refrain from colors ("extra grey stuff") where it doesn't highlight things.
I can live with many things, including all shades of grey. Just trying to improve things (like everyone else I guess).
P
- Lucas Cordiviola lucarda27@hotmail.com [2022-11-22 21:18]:
Ok, this can be discussed and improved.
So now the issue is just about some *extra* grey stuff?
(but you can live with it, right?)
--
Mensaje telepatico asistido por maquinas.
On 22/11/2022 16:15, Peter P. wrote:
I am putting up a proposal about using colors in vanilla the help patches for discussion. I think these patches should
- Emphasize and encourage users to use the color features of GUI elements by showing that in their respective help patches.
- Use colors in vanilla help patches to highlight essential objects and actions, for example to indicate the one single bang button I need to press to start an example therein.
- Stick to the non-color versions otherwise when no highlighting is necessary, as for example the toggles for loudspeaker channels in testtone.pd
Looking forward to a fruitful discussion, P
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em ter., 22 de nov. de 2022 às 18:00, Peter P. peterparker@fastmail.com escreveu:
I am looking forward to get a discussion going, but for this we need more views from others.
From my experience, this discussion is getting quite special attention in
this list with 35 messages so far (and counting). I counted a dozen people engaged. This is about as good as it gets... Moreover, I did a facebook poll which now amounts to 33 votes. You sent 13 emails already and people are still responding to you. Some people probably just decided not to get into this and are aware. Between the list and facebook, that's at least 50 people. Don't worry, this is on!
I counted only 2 people strongly opposing to colors, yours and bbob's but you're the one really going for it :) Not that I wanna say you shouldn't. Where I'm getting at is that it seems you're not succeeding in resonating your voice. The bottom line is: I think this discussion *is* going and happening, but maybe not the way you'd hope...
cheers
Em ter., 22 de nov. de 2022 às 18:00, Peter P. peterparker@fastmail.com escreveu:
I would indeed see an improvement to refrain from colors ("extra grey stuff") where it doesn't highlight things.
Ok. I can see that.
But now problem changed again. It's not "*color is bad because a student may get confused*" anymore. I said this shouldn't be a concern and you might agree because it seems colors are ok "*as long as they mean or highlight something*".
You see, I wanted to propose a solution that could make everyone happy. If the problem was that the default color is white, and people would ask "*why is this bang grey unlike the default white color?*", or people would have a hard time changing the color of something they copied from a help file that is not the default color they're already supposedly using, I thought I'd propose that the default colors of iemguis were light gray then. That would theoretically fix this pedagogical issue. Not only that, but the default color of [cnv] is also already the light grey color I use. We get a full consistency pack. This would really solve the problem.
But the actual issue seems something else, that colors must "mean" something, otherwise it must be "white"... If so, we're back to the first thing I assumed, that this is just a matter of aesthetics, of taste, hence, it's quite subjective. Not that this is "bad", you're free to come here and say you hate it for whatever subjective reason. It's not invalid but it makes a difference if something is based on objective real life problems and examples (like "*now all of my students are lost and my course flow is really ruined, all of them are complaining about this*") or if it's something like "*hey, I didn't like it, it bothers me personally, I like things to be plain white unless they are trying to tell me something special*". We can get the discussion going in a much better flow with honesty and clarity.
I'd be onboard to change the default color if others don't mind, but if that is not the case and you (and others who are sad) are just personally annoyed, I'm sorry, but there would need to be a broader consensus that this is bad. With my facebook poll and others here saying they either appreciate my efforts or are not particularly annoyed by this particularly. There is only about 5% clear opposition and request to change this to plain white, which I don't think makes a good case for you. You gotta respect a little democracy. You questioned the facebook poll as if it was answered by a class of people that shouldn't be considered, but I hope you accept it.
We can keep waiting for others to join in and see where this goes. I might be proven wrong. I might be missing something maybe (please, anyone, tell me then), but this seems settled to me.
What do you say?
I can live with many things, including all shades of grey.
great
Just trying to improve things (like everyone else I guess).
Yeah, I can say my aesthetical choices do aim this purpose of improving things on the behalf of the community, taking into consideration the feedback I've heard countless times over the years from many people complaining about Vanilla's help file and praising extended's (for instance). I pursue this goal with passion and clinical obsession. You won't believe the minor details and hundreds and hundreds of edits I've made to change minute details, like moving object boxes a pixel to the left so connections are perfectly aligned. I don't do this only from untreated OCD, I do strongly believe that all many minor unnoticeable details do sum up and amount to perceivable results that improve this like clearness, readability, comfortness, making it more appealing in general... and it seems to be working...
Take that into consideration if you lose this one. If you can live with this, please do and note that an overall perception is that this is considered as an improvement.
Cheers.
P
- Lucas Cordiviola lucarda27@hotmail.com [2022-11-22 21:18]:
Ok, this can be discussed and improved.
So now the issue is just about some *extra* grey stuff?
(but you can live with it, right?)
--
Mensaje telepatico asistido por maquinas.
On 22/11/2022 16:15, Peter P. wrote:
I am putting up a proposal about using colors in vanilla the help patches for discussion. I think these patches should
- Emphasize and encourage users to use the color features of GUI elements by showing that in their respective help patches.
- Use colors in vanilla help patches to highlight essential objects
and actions, for
example to indicate the one single bang button I need to press to
start an example
therein.
- Stick to the non-color versions otherwise when no highlighting is necessary, as for example the toggles for loudspeaker channels in testtone.pd
Looking forward to a fruitful discussion, P
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 23/11/22 4:58 am, Peter P. wrote:
more views from others.
Whoever paints the community bike shed gets to pick the colours.
[My completely subjective and weakly held preferences on this matter will remain locked away in a super secret Miller-Puckette-style-über-minimalism loving corner of my mind. No no no you can't have my preferences get away from me.]
Cheers,
Chris.
- Chris McCormick chris@mccormick.cx [2022-11-23 03:45]:
On 23/11/22 4:58 am, Peter P. wrote:
more views from others.
Whoever paints the community bike shed gets to pick the colours.
Haha, lovely! Thanks Chris!
Em ter., 22 de nov. de 2022 às 23:46, Chris McCormick chris@mccormick.cx escreveu:
Whoever paints the community bike shed gets to pick the colours.
Funny and brilliant :)
For the record, I just realized default colors of iemguis is note "pure white" as we've been discussing.
Sure it is "witheish", more precisely, it is "FCFCFC" instead of "FFFFFF" (pure white). So a very light grey color (99% brightness in the grey scale). This is not a regression, it's the same in pd 0.48, which I also tested.
I don't know why or where that happens in the code
cheers
Em sex., 25 de nov. de 2022 às 21:09, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em ter., 22 de nov. de 2022 às 23:46, Chris McCormick chris@mccormick.cx escreveu:
Whoever paints the community bike shed gets to pick the colours.
Funny and brilliant :)
On Mon, 2022-11-28 at 02:58 -0300, Alexandre Torres Porres wrote:
For the record, I just realized default colors of iemguis is note "pure white" as we've been discussing.
Sure it is "witheish", more precisely, it is "FCFCFC" instead of "FFFFFF" (pure white). So a very light grey color (99% brightness in the grey scale). This is not a regression, it's the same in pd 0.48, which I also tested.
I don't know why or where that happens in the code
I haven't checked the code, but the old encoding allowed for only 6 bits per channel. Assuming the two least significant bits are set to 0, FC is the highest value possible in that scheme
0xFC = 0b1111 1100
Roman
Em seg., 28 de nov. de 2022 às 05:05, Roman Haefeli reduzent@gmail.com escreveu:
On Mon, 2022-11-28 at 02:58 -0300, Alexandre Torres Porres wrote:
For the record, I just realized default colors of iemguis is not "pure
white" (...)
it is "FCFCFC" (...) This is not a regression, it's the same in pd 0.48,
I don't know why or where that happens in the code
I haven't checked the code, but the old encoding allowed for only 6 bits per channel. Assuming the two least significant bits are set to 0, FC is the highest value possible in that scheme
0xFC = 0b1111 1100
It's much simpler than that. Default color is explicitly set and defined as "0xFCFCFC" in g_all_guis.c, more specifically here:
https://github.com/pure-data/pure-data/blob/06ecc41f42059bfe02081e4738ed21f6...
default "front" and "label" colors are also set there as black.
[cnv] has different default colors specified in its code (0xE0E0E0 for background and 0x404040 for label);
i think what roman is trying to say is that the color was indeed displayed as white back in the days (in 6bit) and the two trailing zeros are there because the value was shifted two positions to the left (<< 2 binary operation) to align with 8bit variables more conveniently... (or maybe i misunderstood completely)
On Tue, 29 Nov 2022, 02:56 Alexandre Torres Porres, porres@gmail.com wrote:
Em seg., 28 de nov. de 2022 às 05:05, Roman Haefeli reduzent@gmail.com escreveu:
On Mon, 2022-11-28 at 02:58 -0300, Alexandre Torres Porres wrote:
For the record, I just realized default colors of iemguis is not "pure
white" (...)
it is "FCFCFC" (...) This is not a regression, it's the same in pd 0.48,
I don't know why or where that happens in the code
I haven't checked the code, but the old encoding allowed for only 6 bits per channel. Assuming the two least significant bits are set to 0, FC is the highest value possible in that scheme
0xFC = 0b1111 1100
It's much simpler than that. Default color is explicitly set and defined as "0xFCFCFC" in g_all_guis.c, more specifically here:
https://github.com/pure-data/pure-data/blob/06ecc41f42059bfe02081e4738ed21f6...
default "front" and "label" colors are also set there as black.
[cnv] has different default colors specified in its code (0xE0E0E0 for background and 0x404040 for label);
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Tue, 29 Nov 2022, 02:56 Alexandre Torres Porres, porres@gmail.com wrote:
Em seg., 28 de nov. de 2022 às 05:05, Roman Haefeli reduzent@gmail.com escreveu:
On Mon, 2022-11-28 at 02:58 -0300, Alexandre Torres Porres wrote:
For the record, I just realized default colors of iemguis is not "pure white" (...) it is "FCFCFC" (...) This is not a regression, it's the same in pd 0.48,
I don't know why or where that happens in the code
I haven't checked the code, but the old encoding allowed for only 6 bits per channel. Assuming the two least significant bits are set to 0, FC is the highest value possible in that scheme
0xFC = 0b1111 1100
It's much simpler than that. Default color is explicitly set and defined as "0xFCFCFC" in g_all_guis.c, more specifically here:
https://github.com/pure-data/pure-data/blob/06ecc41f42059bfe02081e4738ed21f6...
default "front" and "label" colors are also set there as black.
[cnv] has different default colors specified in its code (0xE0E0E0 for background and 0x404040 for label);
On Tue, 2022-11-29 at 07:55 +0100, Simon Iten wrote:
i think what roman is trying to say is that the color was indeed displayed as white back in the days (in 6bit) and the two trailing zeros are there because the value was shifted two positions to the left (<< 2 binary operation) to align with 8bit variables more conveniently... (or maybe i misunderstood completely)
I thought the value #FCFCFC comes from the 6bit encoding scheme and Alex pointed out that this value is hardcoded as the default value. Now I think, this is the hard-coded default value exactly because of the old 6bit encoding scheme. If the initial values was 0xFFFFFF, you wouldn't have been able to get back to that value once you changed colors in the properties.
From what I remember, the iemguis never were exactly white and you
couldn't make them white, at least not with the RGB dialog.
Roman
On 11/29/22 08:14, Roman Haefeli wrote:
I thought the value #FCFCFC comes from the 6bit encoding scheme and Alex pointed out that this value is hardcoded as the default value. Now I think, this is the hard-coded default value exactly because of the old 6bit encoding scheme.
yes.
From what I remember, the iemguis never were exactly white and you couldn't make them white, at least not with the RGB dialog.
you could, but when the color was saved and restored it would become greyish.
gdars IOhannes
On 11/22/22 20:15, Peter P. wrote:
I am putting up a proposal about using colors in vanilla the help patches for discussion. I think these patches should
- Emphasize and encourage users to use the color features of GUI elements by showing that in their respective help patches.
- Use colors in vanilla help patches to highlight essential objects and actions, for example to indicate the one single bang button I need to press to start an example therein.
- Stick to the non-color versions otherwise when no highlighting is necessary, as for example the toggles for loudspeaker channels in testtone.pd
and please get rid of blue labels. e.g. the sliders-help.pd has a prominent blue "Sliders" label i nthe center of the patch.
now blue is a significant color in Pd patches: it shows which thingies are selected. so i always try to deselect the text when i have the sliders-patch open.
mgfds IOhannes
-
Alexandre Torres Porres -
Chris McCormick -
Dan Wilcox -
IOhannes m zmölnig -
Lucas Cordiviola -
Max -
Peter P. -
Roman Haefeli -
Simon Iten