General Approach To Color Palettes

[Arnie Fufkin]

I've been looking at the default color palette as a matter of selection/comparison with multiple other apps I use for various designs.

I started on the forums asking a few simple questions, and eventually got referred here. So I'm posting this knowing it'll likely get wishlisted.

I searched the existing bug reports/wishlisted for "color" and found a number of bugs where similar concerns have been expressed. (Esp #3) I've attached links below.

Currently, I have one question: Where do I find the code that assigns the palette colors to the layers in eeschema / pcbnew. I'm in the process of assessing an approach that would dramatically improve/resolve the problems mentioned in the identified bugs. It would require playing around a bit with the current palette as well.

I've put together a lengthy document of my "research" available for review soon if anybody is interested. You can email me directly if desired, or refer me to an appropriate devlist recipient.

Arnie

(1) https://bugs.launchpad.net/kicad/+bug/1795515

SEPARATE COLOR PROFILES FOR PRINTING AND SCREEN

(2) https://bugs.launchpad.net/kicad/+bug/1678345

IMPLEMENT COLOR THEMES

(3) https://bugs.launchpad.net/kicad/+bug/1491123

DEFAULT TOP/BOTTOM COPPER LAYERS ARE BAD FOR COLOR BLINDNESS

(4) https://bugs.launchpad.net/kicad/+bug/1530637

USER-DEFINED NETCLASS COLOURS

[Anton Savov (antto)]

maybe slightly related:
i wish there was an easier way to change the colors/settings of the 3D Viewer, like, i could make a few "presets" for more realistic-looking green, yellow, blue, red, white, black, etc.. with various combinations of gold, copper, HASL..
right now it's possible only by hacking around with the config files (but there are many other settings contained in it besides these colors)

[Jeff Young (jeyjey)]

They’re fetched through RENDER_SETTINGS::GetColor() and GetLayerColor().

I’m not familiar with the other side (ie: how they get in there).

> On 11 Feb 2019, at 18:25, Anton Savov <email address hidden> wrote:
>
> maybe slightly related:
> i wish there was an easier way to change the colors/settings of the 3D Viewer, like, i could make a few "presets" for more realistic-looking green, yellow, blue, red, white, black, etc.. with various combinations of gold, copper, HASL..
> right now it's possible only by hacking around with the config files (but there are many other settings contained in it besides these colors)
>
> --
> You received this bug notification because you are a member of KiCad Bug
> Squad, which is subscribed to KiCad.
> https://bugs.launchpad.net/bugs/1815376
>
> Title:
> General Approach To Color Palettes
>
> Status in KiCad:
> New
>
> Bug description:
> I've been looking at the default color palette as a matter of
> selection/comparison with multiple other apps I use for various
> designs.
>
> I started on the forums asking a few simple questions, and eventually
> got referred here. So I'm posting this knowing it'll likely get
> wishlisted.
>
> I searched the existing bug reports/wishlisted for "color" and found a
> number of bugs where similar concerns have been expressed. (Esp #3)
> I've attached links below.
>
> Currently, I have one question: Where do I find the code that assigns
> the palette colors to the layers in eeschema / pcbnew. I'm in the
> process of assessing an approach that would dramatically
> improve/resolve the problems mentioned in the identified bugs. It
> would require playing around a bit with the current palette as well.
>
> I've put together a lengthy document of my "research" available for
> review soon if anybody is interested. You can email me directly if
> desired, or refer me to an appropriate devlist recipient.
>
> Arnie
>
>
> (1) https://bugs.launchpad.net/kicad/+bug/1795515
>
> SEPARATE COLOR PROFILES FOR PRINTING AND SCREEN
>
> (2) https://bugs.launchpad.net/kicad/+bug/1678345
>
> IMPLEMENT COLOR THEMES
>
> (3) https://bugs.launchpad.net/kicad/+bug/1491123
>
> DEFAULT TOP/BOTTOM COPPER LAYERS ARE BAD FOR COLOR BLINDNESS
>
> (4) https://bugs.launchpad.net/kicad/+bug/1530637
>
> USER-DEFINED NETCLASS COLOURS
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kicad/+bug/1815376/+subscriptions

[Wayne Stambaugh (stambaughw)]

I believe someone already sent a patch for review to the developers mailing list for user defined color palettes although I don't think this was general approach. I don't think the patch has been reviewed because it would not be allowed until v6 development opens which should be soon. Please search the dev mailing list and coordinate with other developers before you spend any time working on this so you don't waste your time duplicating this feature.

[Arnie Fufkin (ubuntcpmb)]

The colors are defined in colors.cpp file as an ENUM type.

I've been looking at coming up with a better palette of presets. I started with other CAD programs and have come up with about 18 colors that present well on screen and print. I'm planning to do a build with those color values and see how they look. Also going to look at these color "themes" mentioned in one of the bugs I pointed out.

These would form a better default color palette, as opposed to user defined colors which could be just about anything, especially given the 4color picker that has been implemented.

Thanks for the info, I'll take a look at that code. Also considering a special palette for color blindness since I have a significant education in medicine as well as my dozen other vocations.

Cheersies.

[Arnie Fufkin (ubuntcpmb)]

*** ACK! BLAH! ***

Okay, did some poking around and found those functions and the default assignments.

They are in colors_design_settings.cpp:

static const EDA_COLOR_T default_layer_color[] = {

static const EDA_COLOR_T default_items_color[] = {

COLORS_DESIGN_SETTINGS::COLORS_DESIGN_SETTINGS( FRAME_T aFrameType )

COLOR4D COLORS_DESIGN_SETTINGS::GetLayerColor( LAYER_NUM aLayer ) const

void COLORS_DESIGN_SETTINGS::SetLayerColor( LAYER_NUM aLayer, COLOR4D aColor )

Etc....

[Jeff Young (jeyjey)]

@Arnie, are you still looking at this? Should I assign the bug to you?

[Arnie Fufkin (ubuntcpmb)]

Yeah, was hoping to get back to it this week and do that. Did it anyway. I'm expecting submission openings for next version and hoping to have something solid by then. Anybody have a timeline on that??

[Jeff Young (jeyjey)]

@Arnie, good question. 2 to 6 weeks would be my best guess, but @Wayne would have a better idea.

[Wayne Stambaugh (stambaughw)]

Once 5.1 is branched we can start merging v6 changes. That should happen by this weekend unless yet another critical bug get reported before then. I still have to prioritize the list of merges that are ready to go which I will do before 5.1 gets branched but it should be more than a month or so until everything is merged and v6 is under heavy development.

[Arnie Fufkin (ubuntcpmb)]

So I've done a successful build with MSYS2, and made some initial mods to a few files, I'm about to do a test build But...

Q1: Definitions of CMAKE_INSTALL_PATH DEFAULT_INSTALL_PATH

Reading through a few of the makefiles, it appears that CMAKE_INSTALL_PATH is where all the targets should go. So if I change it to:

 -DCMAKE_INSTALL_PATH=/kicadexe_source

everything should end up in C:\msys2\kicadexe_source right?

I assume that CMAKE_PREFIX_PATH is for source file search?

Do I need to specify DEFAULT_INSTALL_PATH the same as the install path???

Q2: I've got only a few files I'm affecting (I think):

 /common/colors.cpp
 /common/plotters/DXF_plotters.cpp

 /include/colors.h

Given a 3 hour build time, I don't have a whole life to build, test, fix, build, test, fix, etc.

How can I speed this up using make targets ? Can I assume that as long as I don't 'make clean' only dependency affected code should rebuild ?

I've noticed a 'test' target...should just do 'make test' ?

Or do I need to build a smaller make file from 'build/release/Makefile', and go fishing for dependencies to resolve?

Or should I add a target to 'build/release/cmake_install.cmake' ?

Much thanks.

[Wayne Stambaugh (stambaughw)]

@Arnie, unless you are creating package builds where you need a different path than CMAKE_INSTALL_PATH, you don't need to set DEFAULT_INSTALL_PATH separately as it defaults to CMAKE_INSTALL_PATH. Just set -DCMAKE_INSTALL_PATH=/path/to/install/kicad when you run cmake and you should be fine. FYI, development questions like these should be posted to the developers mailing list. This prevents the bug report being polluted with information that is not related to the actual bug.

[Anton (antonpupkov)]

You may need to enter a palette based on html code in kicad, For example, #000000 or #FFFFFF.

[Michael Kavanagh (michaelkavanagh)]

@Arnie, are you still looking at this? What is the status on your proposed patch? I know @Jon Evans is planning on working on this area during v6. To avoid duplicating effort, I think we should mark this report as a duplicate with https://bugs.launchpad.net/kicad/+bug/1678345