That looks strange. Especially for text. A colour change might look better i think. (One could for example choose opposite colours on the colour weel or something like that if one does not want to manually define a highlight colour for everything.)
Are the highlight colors user settable? This would be nice in order for highlight to work with kicad-color-schemes, especially dark ones.
@JeffYoung already asked for feedback about the highlight visuals on the dev mailing list: https://lists.launchpad.net/kicad-developers/msg41937.html. Maybe the discussion could be moved to a new thread if it continues.
It is hard to give feedback without seeing what one talks about. Maybe posting screenshots to the mailing list might be a good idea when asking for feedback regarding the GUI. (I am unable to use nightlies as i am one of the library maintainers.)
I’ve checked. The highlight colour is not user settable. Thus on dark color schemes it does not look alright @JeffYoung.
KiCad default colour scheme:
Blue-tone:
Solarized-light:
Solarized-dark:
Behave-dark:
Tested on:
Application: KiCad
Version: (5.99.0-6-gbc0e67579), release build
Libraries:
wxWidgets 3.0.4
libcurl/7.61.1 OpenSSL/1.1.1 (WinSSL) zlib/1.2.11 brotli/1.0.6 libidn2/2.0.5 libpsl/0.21.0 (+libidn2/2.1.1) nghttp2/1.34.0
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.68.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.61.1
Compiler: GCC 8.2.0 with C++ ABI 1013
Build settings:
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=OFF
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=ON
For reference this is how it works in eagle version 9.4.2 (This is the alternative software i have access to. Maybe somebody with access to altium could show their solution.)
Default (quite hard to see what is selected)
With high contrast mode enabled
colour shift of high contrast mode can be controlled via a hue slider
The main benefit of eagles system is that text is still readable, the same highlighting can therefore be used for both showing a selection and highlighting a net (including labels and pins). And symbols with a lot of detail stay readable (I wonder how the mosfet symbol of the official lib looks like with the current highlighting.)
Another benefit of eagles system is that one does not need to define a highlight colour as it is calculated relative to the normal colour. (one defines by how much it should change which makes more sense)
Drawback of the eagle system is that it does not work with grayscale elements (have 0 saturation so changing the hue value does not change the colour at all. I am sure there could be a solution found for this as well. One example would be to additionally allow for changes to the lightness value.)
The first versions used a scheme similar to Eagle’s. However, it loses the colour distinctions between elements.
I then tried just brightening the colour (as is done in Pcbnew), but that’s really hard to see on a white background. I also tried bolding, but it looked horrible.
The current selection colour is picked up from the OS, which should prevent exactly the type of issue @MitjaN is seeing. Are those themes Kicad themes or MSW themes? (It’s possible wxWidgets is buggy and doesn’t return the system highlight colour correctly on MSW, but I can’t test that as all I have is OSX.)
KiCad themes from https://github.com/pointhi/kicad-color-schemes
If it is truly similar to eagles high contrast mode then i highly doubt that it is hard to see. (Or is it hard to identify what is selected in my screenshots above?)
to make it clear: eagle shifts all colours by the same amount. My guess is they doe a rgb to hsl conversion and than add some value to the hue depending on where the slider is. But it also increases the lightness, so they additionally add some constant non changeable value to it. (if i place the selector somewhere in the middle no colour change happens but selected appears brighter -> so the same as without selecting the high contrast mode)
Sounds strange. Why should the drawing area colors have anything to do with the system (OS) colors? Anyways, as we saw, it cannot work because the user can change the other colors. The logical (and better working) solution is to make it configurable.
Because that way the colours react to changing OS themes. But if we also have Kicad themes, then there’s no way to please both…
Something must know the actually shown colour. (as something needs to generate it for the graphics card)
alternatively: proper theme management (selection possible between os based or user defined, import export, …)
I don’t think this is necessary. Pcbnew’s drawing area doesn’t do that, either. I understand eeschema is a bit different, but I don’t expect it to look like my OS theme. And the OS theme is meant for normal GUI elements (buttons, text boxes etc.) anyways, not for special graphics.
I don’t see why we could not just highlight it with the highlight colour the way the nets are highlightet using net highlight tool. Yes you could not differentiate between different items but neither can you in pcbnew using brighten functionality(BTW pcbnew brighten color is not user settable). But at least user could adjust the colour.
As for how the colour should be derived I think that there are two aspects to the program. The canvas and the UI. What is on canvas should be set by KiCad colour controls. And what is on UI shoud be derived from OS setting. Now if the user is running light OS theme and dark theme on canvas at least he/she can configure canvas colors so that there is minmal conflict. If you derive canvas colors from OS setting then the pcbnew highlight colour should also be the same dark blue(on windows at least as ther is no dark Os theme). And I am pretty certain this would not go through wit current users. But as I am not a designer and I don’t have a clue regarding desing I am pretty sure I missed something fundametntal.
@craftyjon is working on this now [1]. The exact color should probably be configurable in the KiCad themes as well.
FWIW, I find Eagle’s approach substantially inferior to Jeff’s. Back when I used Altium, they did a hatch-pattern on highlighted objects that was similarly unpleasant.
A hatch pattern sounds similar to the halo used by jeff. (But yea i get that it would be even worse.)
My main problem with the halo approach is that it simply makes it hard to read text or identify small details (like the plus and minus sign of the OPA in the screenshots above) This problem arises from the fact that everything becomes thicker. Which is not a problem with the eagle approach (that only changes the colour and leaves thicknesses unchanged.)
I’m working on a blur shader that should help this. The trick will be to make it not slow cairo to unusable levels.
commit 548dbb7c29513280ddde81262a5039376ac9f5d0 (HEAD -> master, origin/master, origin/HEAD)
Author: Seth Hillbrand <>
Date: Mon Aug 26 21:43:59 2019 -0700
eeschema: Add highlight color to configurable list
The highlight color chosen from the system highlight doesn't always show
against the schematic sheet background color. Allowing the user to
customize with their KiCad theme makes it configurable on par with other
colors. This is stop-gap until we get full color schemes from
lp:1678345I’ve modified Seth’s default to be a much lighter blue (similar to the OSX system highlight). This should help the text readability and detail obscurity issues quite a bit.