Track color mixing gone in 5.0?

After a pause of over a year of not working with KiCad, a new project has started now using 5.0 rc2.

I see a significant difference in graphic representation. Until inclusive v4.0.x, crossing lines (e.g. bottom & top track) appeared mixed, e.g. violet when tracks are red resp. blue.

I inspected the 3.x and 4.x versions, and there seems no such parameter to enable this behaviour. That means: it would be the standard, only behaviour.

BTW: the new opacity mode is another type of mixing. I’d consider the old mixing type better, especially when one could switch it on and off via a simple button click and/or a hotkey. At any case, the new handling has the advantage of putting the current active layer into the foreground.

The old behaviour is still available. Press F9 to go to the legacy canvas. And F11 to come back to opengl canvas.
I was also used to the legacy canvas opacity. It takes some time to get used to opengl and get the color settings that make one feel comfortable.

Answer: I just discovered this, and while writing this answer, I’m quite happy. I remembered that the rendering machine could be selected in V4 too.

In current nightly (what you call v5) you can select transparency for layers also in open gl canvas. (In the same way as you would select the layer colors. By middle clicking on the colored square next to the layer name)

There are also keyboard shortcuts for adjusting the transparency of the currently selected layer.

[ (square left bracket) will increase transparency.
] (square right bracket) will increase opacity.

Disclaimer: This is true on my US keyboard map on Win10x64 using a nightly from last week.

2 Likes

Help->List Hotkeys shows what they are, here it’s {}. But I don’t think it’s working. Nothing happens. Changing the opacity value in the color dialog works.

Are you sure you weren’t holding down the cmd (or ctrl) key? They’re just Shift + { and Shift + }.

If that doesn’t work, what platform and version are you on?

In this Finnish layout they are behind AltGr (AltGr+7 and AltGr+0). Is this a bug? If I redefine them by pressing AltGr+7/0 it becomes Ctrl+Alt+7/0 in the Hotkeys Editor. Then it actually works with AltGr, i.e. with { and } characters in my layout.

Application: kicad
Version: (5.0.0-rc2-dev-661-gcad2d0656), release build
Libraries:
wxWidgets 3.0.3
libcurl/7.55.1 OpenSSL/1.0.2g zlib/1.2.11 libidn2/2.0.2 libpsl/0.18.0 (+libidn2/2.0.2) librtmp/2.3
Platform: Linux 4.13.0-39-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
Boost: 1.62.0
Curl: 7.55.1
Compiler: GCC 7.2.0 with C++ ABI 1011

Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_SPICE=OFF

For the US citizens who don’t know what AltGr is here is an explanation: https://en.wikipedia.org/wiki/AltGr_key. It also shows the reason why it becomes Ctrl+Alt, although I regard it as a bug in KiCad or maybe in the underlying wxWidgets.

Could well be a bug, but I usually head for the exits when HotKeys/CtrlKeys/Modifiers are involved.

Fortunately Wayne and JP appear to be fluent in this area. :slight_smile:

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.