Duncan posted on Wed, 17 Jul 2024 13:07:48 -0000 (UTC) as excerpted: > There may be other bugs, and for sure the bugs above seem to apply to > more than Other Text, but it's hard to test and actually confirm > anything until it's being written to config and shows up in a > prefs/colors reload, so best to wait until those bugs are fixed first, > before seeing if there's another batch after that.
So I dug up a backup preferences.xml and compared my old #xxyyzz values to the new rgb(xxx,yyy,zzz) values. The real good news is that whatever is doing the conversion seems to be rock solid -- all the values I hadn't messed with since seem to have been correctly converted and stored in their new form. =:^) Further good news, since I've visited prefs/colors multiple times and the default values it appears to be loading there didn't overwrite the successfully converted values, it appears the prefs/colors code DOES correctly flag changes and only overwrites what actually changed, even if it's loading the default colors instead of the customized values. (IOW, it's NOT overwriting my customized colors with the defaults as I feared it might be (with that fear discouraging too much experimentation), despite loading the defaults instead of properly loading my customized settings. That's a good thing!) So the three big bugs so far remain: 1) The prefs/colors display code is not loading the user's custom colors for display, so it's always displaying app defaults. This appears to apply to all colors displayed in prefs/colors so it's likely a bug in the generic loading or display code. 2) When prefs/colors changes are made and OK in the prefs dialog pressed, the changes aren't immediately written to preferences.xml as they should be. The preferences.xml file doesn't appear to be updated until graceful shutdown after making changes, meaning if pan crashes instead of graceful shutdown, those changes are likely lost. 3) Some changes made in prefs/colors aren't reflected in the running pan instance either, tho some appear to be. (Setting red-on-black for other text doesn't reflect the red foreground change but does seem to reflect the black background change resulting in unreadable black-on-black, until the changes are properly written on graceful shutdown and picked up on restart.) To that I can add that some color settings don't seem to be properly initialized from preferences.xml at pan startup either, despite them being properly set in that file. App default colors are then used for those settings. I've not yet itemized the specific affected settings, but now that I know the preferences.xml format conversion seems to have been done correctly, I can take a new backup of that and start trying to figure out which settings pan's loading properly at startup and which ones its not. So expect another followup with that. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
