reflect palette in gui, use for cords_to_foreground - #2692

removed the commit changing colors to color message and swapping foreground and background arguments. i assume that these shouldn't be changed anymore after the release of Pd0.56-0.

Is this good for 0.56-1? :) I say fixing cord highlighting is an important bug fix. I hope this gets considered - ping @millerpuckette

is it possible to put the logic in the C code instead of the tk?

Sure. If I remember correctly, that's how I first did this on another PR

please do not.

right now, the core does not know anything about the "cords to foreground" - it is entirely implemented on the GUI side.
if a prospective GTK version wants to have the same functionality, it can easily implement it all by itself. or ignore it.

i'm really opposed to moving GUI-only stuff over to the core, only to save a bit of implementation for a potential GUI written in another toolkit. in the end this all boils down to: "if you want to write a GUI in GTK/JUCE/FooWdiget, you just have to implement your own TclTk layer for your fancy toolkit". but:

• implementing Tcl/Tk (or just Tk) is a non-trivial operation, and a very easy way to introduce very serious bugs
• these toolkits already have their own idiosyncratic ways to handle things
• adding another (complext) layer on top of an existing toolkit is very likely to destroy all the benefits you ever get from the new toolikt. if your brandnew JUCE-based GUI looks identical to the 90ies-style Tcl/Tk GUI and performs worse (because of the additional translation layer, that effectively circumvents all performance improviements), why would you want to re-implement such a GUI in the first place?

because @porres is re-iterating this:

Is this good for 0.56-1? :) I say fixing cord highlighting is an important bug fix.

i think not.

• there are "millions" of background/foreground combinations where the currently hard-coded color for backgrounded cords is perfectly visible.
• if you happen to pick a combination where this is not true, you can easily switch off the "Highlight active cord" functionality in the GUI properties
• if you cannot live without the "hightlight active cord", you can probably live with the fact that you do not see the already-connected (non-active) cords while connecting

i totally agree that it is ugly, and annoying.
and that it should be fixed.
i just don't see how this is an important issue. instead i would label it as "very minor".