For reference, I’m running Pop!_OS 22.04 (Ubuntu-derived Linux distro), with the desktop set to the built-in “Dark” theme.
In any dialog in KiCad, where there are text fields, any text field that’s in an active row but out of focus renders with black-on-gray:
This includes the whole row, if the dialog loses active state for taking a screenshot like this. If the text field has a cursor in it, then its every part of the row besides the field with the cursor.
Additionally, every once in a while KiCad has this habit of rendering an entire active text edit field as the background color, presenting the effect of that text field simply being non-functional when I click on it. However, I can still copy out of it with Ctrl-C, and if I blindly type content then it does get set to the value. I’d share a screenshot, but for some reason this bug is intermittent and I cannot reproduce it on demand.
If v7 wasn’t right around the corner, I’d consider attempting to directly file bug reports over these issues. But because it is, I’ll wait for v7 to drop and then test again. Just want to know if anyone else has run into these issues, or knows of a fix/workaround.
(It very well may be due to bad dark theme support in wxWidgets, as I’ve had similar sorts of problems in HTerm.)
It’s kind of a extremely difficult to fix issue because it’s theme specific and often an issue in the theme
In general PopOS isn’t a supported distro so even if its the default theme, its not going to get much loving
So the first issue is definitely theme related. Though the process of figuring out exactly which theme field is causing this issue, so the appropriate bug can be filed in the appropriate place, will require attempting to tear apart KiCad or wxWidgets code. Unless someone here just knows. (If I explicitly force the “Adwaita-dark” theme instead of the built-in “Pop-dark”, that issue doesn’t appear.)
As far as the second issue, I think its an actual bug. I also just figured out how to reproduce it. And it happens regardless of theme.
Open the Symbol Properties for a schematic symbol
Click on the field “Name” element for something in the list
Immediately click on the “Value” area adjacent to it
Notice that the value area goes completely blank.
Apparently, though, moving focus out of the dialog and back seems to clear up whatever the issue is. Its also at least a little bit intermittent, and if you somehow don’t do step 2 just right, it might not happen.
There are differences. 6.99 has no boxes drawn and the value is automatically extended to allow the whole footprint and data sheet values to be displayed.
And just to make everyone happy, I rage-installed Ubuntu 22.04 LTS in a VM, installed the latest 6.0.x version from the PPA, and was able to reproduce this field-blanking bug there.
Application: KiCad
Version: 6.0.10-86aedd382b~118~ubuntu22.04.1, release build
Libraries:
wxWidgets 3.0.5
libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.13
Platform: Linux 5.15.0-57-generic x86_64, 64 bit, Little endian, wxGTK, ubuntu, wayland
Build Info:
Date: Dec 18 2022 19:39:39
wxWidgets: 3.0.5 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
Boost: 1.74.0
OCC: 7.5.2
Curl: 7.86.0
ngspice: 36
Compiler: GCC 11.3.0 with C++ ABI 1016
Build settings:
KICAD_USE_OCC=ON
KICAD_SPICE=ON
I don’t think its dark-theme specific. I’ve also reproduced it with light themes. But it is kinda intermittent. Sometimes I can reproduce it consistently, and sometimes I can’t reproduce it at all. Maybe its related to the ordering of window focus events, but I’m really not sure.
I have the same pop-os 22.04 and the exact same kicad field thing in dark mode, both 6.0.10 and 6.99. I just shrugged it off for now as it is an oddity and not corrupting anything. I get my work done but it is a bit annoying. I love the dark theme though, and I love pop-os, as opposed to the generic ubuntu that seems just old, like x-windows on sun workstations old, or perhaps a bit more refined like 90s silicon-graphics boxes. I did enjoy mint for a while, but too windows-like for me. I played with several other distros and settled on pop (but added nemo).
I spend some time digging into it a little bit, and I think the crux of the first problem is that the Pop-dark theme is not correctly setting whatever key ultimately gets translated into “wxSYS_COLOUR_HIGHLIGHTTEXT”. It always comes back as a 0 with that theme, but with a real value on other dark themes.
So at least that issue is most likely a theme bug, and I’ll try to report it to the Pop!_OS folks as soon as I manage to discover exactly what they managed to foul up.
Good to know the real bug is upstream. I only hope someone bothers to back-port wxWidgets, otherwise I’ll have to just live with it for a while, or run my own custom build of the KiCad stack.
As far as the theme issue, I did a bit more poking, and I think the actual culprit is whatever theme attribute maps to “wxSYS_COLOUR_LISTBOXHIGHLIGHTTEXT”. In the code for wxWidgets, it explicitly describes it as:
“This is for the text in a list control (or tree) when the item is selected, but not focused.”
(and its gotta be one of those two, because they’re the only “TEXT” keys in the entire available set that return as 0 for that theme)
Regardless, trying to decipher structure of a Gtk 3 theme to figure out where exactly to fix that is far easier said than done, but at least its progress.
So apparently the light version of Adwaita has a similar issue, but in the opposite direction. Its just not as bad, because white-on-light-gray is more readable than black-on-dark-gray.
Regardless, when I tried filing a bug against my current theme (“Pop-dark”) about this issue, the response I got was: “I believe the problem is that they’re grabbing the text color from a selected GTK TreeView cell, but not the background color. The color should be a light blue, which would still be visible.”
So maybe wxWidgets is messing something up here. Makes me wonder if its fixed in newer versions of wxWidgets, or if more targeted complaining needs to happen.
(FWIW, HTerm is actually much worse than KiCad here. However, HTerm is closed-source and doesn’t pay attention to environment variables for overriding the system theme, so its harder to kludge around the issue there.)
Hello, super noob here, how did you manage to get a full dark theme please ? (the entire software I mean, the menu bars etc, not just the central viewport)
I’ve searched a bit but can’t find comprehensive explanations for version 7 anywhere.
It is my guess that people who did that may have altered the source code of wxWidgets / built the software from source perhaps ? I’d love a little help if someone would be so kind to help
You just set your OS to use a dark theme and it works (on macOS and Linux). If you’re on Windows, you’re out of luck. Microsoft has not made it possible (yet).
What’s interesting is that Windows 11 actually does now have a dark theme mode. I guess its just too new for everyone to have figured out how to properly query and use it. (Especially when going through toolkits like wxWidgets.)
But as far as my original color issues, I’ve kinda given up. Both the KiCad and PopOS Gtk theme folks seem to either point their fingers at each other, point their fingers at wxWidgets, or pretend its not an issue worth caring about.
I think the real culprit here is wxWidgets, but because everyone seems to treat wxWidgets like this evergreen library that’s seldom updated, I think the only way this issue will actually get fixed is with an app or theme level workaround.
Part of the problem is that more popular dark themes, by sheer coincidence, don’t look bad enough to piss off the right people. (Even if they suffer from the same color-mis-picking issue, if you look closely enough.)
The problem is Microsoft has not backported the dark theme to the older Win32 controls and only uses it in the newer UWP controls. This isn’t wxWidget’s fault and requires piles of hacks to try and workaround.
