Linux: on system color change, not all colors update
Closed this issue · 9 comments
Description
This is a known issue that is either down in wxwidgets or wxpython, not Rummage itself. When the system color changes on Linux, we get an event to handle colors. On macOS, most of the colors change automatically, but there are a few places we have to manually manage the color swap. On Linux, there are a few more, and current methods don't seem to work well.
Known colors so far include:
- Date widgets don't properly change the invalid color. This is a minor issue.
- ListCtrl backgrounds and foreground text.
Evaluation
-
Date widget colors can be fixed with some semi ugly hacks. But due to the larger ListCtrl issue, it isn't worth the effort right now.
Basically, we can load up a TextCtrl object, get its system colors, and then set new colors. I don't recall, but we may need to delay the color change with a
CallAfter, but I don't recall. -
ListCtrl requires us to do a
CallAfter, create a TextCtrl so that we can acquire a reasonable background color (we might have had to attach it to a new Frame/Window, and then we can calculate new colors. But after all this, we still can't change the list header background making column headers potentially unreadable.
Recommendation
Because the workaround for ListCtrl cannot fix headers becoming unreadable, the effort to fix the other colors with ugly workarounds is not recommended because the app may still be rendered unusable, even with all the workarounds.
At this time, our best recommendation is to restart the app if you change your system colors.
If at some time in the future Linux wxPython builds can properly swap all the system colors, or we can in a reasonable manner manually change them, we can reevaluate and provide a proper patch.
I've got a couple hacky ideas that I'm going to give try out. There are only a handful of areas we need to manually refresh colors:
- ListCtrls
- TimePickers accent colors
There may be more, but that is all I've found.
The issue is we are able to catch the color change event, but no matter what we do, we can't consistently get the right color. We tried loading up a temporary new textctrl and read it's background and foreground color, but it seems that when we do that, we have to load it in a new hidden dialog, and even then, we only sometimes get some of the right colors. I suspect we may have to defer the update on Linux. Maybe if we give more time, we can actually get the correct colors.
While through some hacks, we can get a number of the colors looking right, there are still some that fundamentally can't be fixed without reloading the entire window.
I'm thinking a popup is probably the best we can do, or simply stating it in the docs. At some point, I imagine wxpython will fix it, but sometimes we have to wait a while.
Upgraded to 4.16 from 4.15 today (skipped 4.15.1) and have a problem with time field when using dark theme. It's simply white (worked fine in previous versions) - https://i.postimg.cc/JhsR3fBn/rummage-white.png
P.S. Also I'm not sure if previous versions displayed date in ISO 8601 format (I have this option enabled, so results are listed as YYYY-MM-DD) in datepicker fields or not (didn't use "Modifed" date field, but noticed it today because of white field next to it).
@toxpal, I know what the issue is for the color. Tested on mac and Windows, but did not test on Linux. Basically, we are avoiding some color code on old macs that is needed on new macs and Linux, but forgot to put in the conditional that it is okay to run the lines on non-mac systems.
As for date element, it's always been whatever the element provides. We have a global international time format that affects results (file modified time and created time), but I never changed the date input field, I'm not sure if you can...I'll check.
I should have a fix for Linux colors coming, but open an issue for the date format. The current control does not expose the ability to change this format, and it is possible that there is no way, but it may be possible for me to augment the control to allow it (maybe). If it is tapping into native elements, then there may be nothing I can do, but we'll see.
For now, I'll get a color fix release out.
Both of these issues (time color and date field) don't bother me much, so no need to rush with new release. As long as Rummage does what I need, I'm happy it exists at all. No single grep GUI alternative for Linux even comes close to Rummage :/
No single grep GUI alternative for Linux even comes close to Rummage :/
Thanks for the kind words! As long as I need to grep files on systems cross-platform, I intend to continue supporting Rummage. There is definitely a Rummage sized hole there.
The fix for colors has already been tagged. I hate when I break things that used to work 😬.
As for time, I'm in no rush to change anything there. Most likely, any changes there will require me to do more work than I want to. It works as-is, but maybe not ideal for all regions, but certainly not broken. It is actually working exactly as expected.
I'm not sure if the time format is sourced from the system (like some global OS setting that you change on the system and it is reflected in the control box) or if it is hardcoded this way in wxPython, but there is no simple flag I can send, so it is low priority.
Colors work fine again on Linux.
Closing issue as the problem is no longer present. Most likely it was a distro-specific bug that has now been fixed, not necessarily a bug in Rummage.