Rockbox Technical Forums
Support and General Use => Theming and Appearance Customization => Topic started by: Frankenpod on August 10, 2019, 04:21:31 AM
-
For example, if you select "files" from the main menu, you first see a menu of the top level directory names. Once you've drilled down through the menus you see the list of files. Now the list of files appears using the foreground colour that has been set, either in the theme or via the colours menu. But the folders/directories list seems to appear in a random colour, not the chosen foreground colour, and I can't see where this colour is set. Often it's a low-contrast colour, like dark blue when the background is black and the foreground is set to white.
Same thing arises when selecting themes from the settings/themes menu.
Am I missing something obvious? How does one set this colour, either within a theme config or elsewhere?
Edit - this doesn't seem to happen on the simulator, only on an actual ipod. On a simulator those mid-level menus use the correct foreground colour. I don't get what's going on.
-
there are some funky things that happen when you invert colors
assuming rgb-24 bit rgb-32bit and get rgb-16bit or visa versa might be the case
of some bad inversion logic
-
IIRC you can change the item selection to an arrow> does that make them display right?
Settings>Them Settings>Selector?
-
IIRC you can change the item selection to an arrow> does that make them display right?
Settings>Them Settings>Selector?
No, that doesn't change it - the arrow is visible (and always green) but the actual text of each menu item remains very dark green or very dark blue - so not very visible when the background is dark. It's not the inversion effect because it's an issue with the entire menu, not just the currently selected line.
Really no idea what is happening, as I say it works correctly for the bottom-level of the directory tree when you actually see the file names, it's only the intermediate level, when you see the folder names, where the foreground colours are not set correctly.
OK, now found it works correctly on some ipods but not others. Now completely confused. Maybe there's some rockbox corruption on the problematic ones...or maybe there's a hidden 'setting' that has gotten set somewhere. Have noticed this glitch intermittently for some time. Guess I need to narrow down when it happens.
-
I think it depends whether you have previously chosen a theme that has a *.colours file. The intermediate level menu colours get set by that file, while the lowest level menu uses the setting from the foreground colour. Once you change to another theme that lacks a *.colours file you can't set those colours directly through the menu system.
Picking 'reset colors' from the theme menu has inconsistent results. Firstly it resets the colours you didn't want to change, and secondly it has odd effects on those intermediate menu colours - e.g. turning them from dark green to dark blue.
Are those intermediate level file browser menus supposed to use different text colour from the 'foreground colour' as set? This is confusing.
-
probably an oversight / bug
-
I know the obvious response is that I should try fixing it myself, but in case anyone more expert is looking at the code, it would be great if someone could make the fix - I would guess it just requires the menu option for 'theme settings/colours/reset colours' to reset (to default foreground colour) _all_ the colours that are changed when the 'colours' file is processed rather than just some of them.
I'm guessing the 'colours' file idea and the reset colours option were written at different times and didn't allow for the other's existence? Few themes seem to bother with a 'colours' file - perhaps it dates from when people were feeling more ambitious about making the entire interface fully customisable?
-
Hi Frankenpod! I think it's easiest if I respond here to your post from the other thread (https://forums.rockbox.org/index.php/topic,53758.msg247932.html#msg247932) so that it isn't dragged off-topic too much, haha. Here's what you wrote:
I notice on the patches list you've fixed the filetype colors bug? If that's the bug I'm thinking of, thanks, because its been, er, 'bugging' me, for a long time. Not sure from the description if it's the same bug, but it sounds like it. What I'm thinking of is when a theme has a colours file that changes the text colours you get when file browsing, but then you can't reset those colours back to default again, so the text becomes unreadable when you use a theme with a different background colour from the one you started with. (Hard to check if it the bug's still there because it only comes up when applying themes that meddle with those colours in the first place.)
Exactly. A theme (or some other config file) can specify custom filetype colors (https://www.rockbox.org/wiki/CustomFiletypeColours) using a line like this:
filetype colours: /.rockbox/themes/filename.colours
and reset it as usual:
filetype colours: -
The latter did not work before until you restarted. Now it should work as expected. Unfortunately, far from every theme includes this line, in fact I've yet to add it my own theme, to make sure the colors are reset.
CenterArtfor the iPod video is an example that includes its own custom filetype colors. That's actually the theme that made me notice the bug when I then switched to another one that tried to unsuccessfully reset the filetype colors.
Funnily enough, I did notice your thread about this only after fixing the problem. I think you're suggesting that Theme Settings->Colors->Reset Colors should also reset the filetype colors. I haven't implemented that but it would be straightforward and sounds like a good idea to me? The only possible argument against it I can think of, is that you would be resetting something which can't be set in that menu in the first place (it currently only contains line selector colors, line separator color, bg color and fg color). Unless it was added there, so that you could choose a different .colours file. But maybe that's not even necessary. Let me know what you think. Anybody else, too, of course.
-
Thanks for that. Along with the "disappearing cover art" bug, that's two long-standing minor but annoying glitches I've been bugged by in rockbox that you've fixed.
If you are looking for anything else to tinker with, would it be a cheek to suggest you look at how the Comment Field code works? Maybe it's a bit too complex to deal with, as I would assume the string-length limitation itself is something quite fundamental to Rockbox. But I was hoping, depending on where that string length limit kicks in, it might be possible to have a second function, say %iM or %iC2 or something to supplement %iC, that would return the _second_ 230 characters of the comment (I'm also guessing that the theme engine parser would be happier with another two-character variable than having to deal with a three-character one). Few comment fields will be more than 460 characters, even the descriptive ones that podcasts tend to have, so that would be enough to solve most of the problem.
https://forums.rockbox.org/index.php/topic,53319.msg246205.html#msg246205
My attempt to show the comment in the style of the original firmware is [note annoying truncation]
http://themes.rockbox.org/index.php?themeid=3126&target=ipod6g
Edit - as for the reset colors thing, personally I don't have a problem with having that menu option reset all the colours, even the ones it can't itself set. Maybe it violates some conceptual notion of how interfaces/devices should work, but I don't see a practical problem with it. I mean, if you "clear backdrop" with the menu setting of that name, it removes every aspect of the backdrop, you can't specifically design every characteristic of a backdrop within the menu system itself, you can only load pre-existing designs. The same would be true with colour settings - you can always load a theme with the colour settings you want.
-
Thanks for that. Along with the "disappearing cover art" bug, that's two long-standing minor but annoying glitches I've been bugged by in rockbox that you've fixed.
Happy to be able to contribute anything at all, however small. Plus, I wanted these fixed myself. :D
If you are looking for anything else to tinker with, would it be a cheek to suggest you look at how the Comment Field code works? Maybe it's a bit too complex to deal with, as I would assume the string-length limitation itself is something quite fundamental to Rockbox. But I was hoping, depending on where that string length limit kicks in, it might be possible to have a second function, say %iM or %iC2 or something to supplement %iC, that would return the _second_ 230 characters of the comment (I'm also guessing that the theme engine parser would be happier with another two-character variable than having to deal with a three-character one). Few comment fields will be more than 460 characters, even the descriptive ones that podcasts tend to have, so that would be enough to solve most of the problem.
https://forums.rockbox.org/index.php/topic,53319.msg246205.html#msg246205
My attempt to show the comment in the style of the original firmware is [note annoying truncation]
http://themes.rockbox.org/index.php?themeid=3126&target=ipod6g
I responded directly in that thread again.
Edit - as for the reset colors thing, personally I don't have a problem with having that menu option reset all the colours, even the ones it can't itself set. Maybe it violates some conceptual notion of how interfaces/devices should work, but I don't see a practical problem with it. I mean, if you "clear backdrop" with the menu setting of that name, it removes every aspect of the backdrop, you can't specifically design every characteristic of a backdrop within the menu system itself, you can only load pre-existing designs. The same would be true with colour settings - you can always load a theme with the colour settings you want.
Yeah, it probably makes sense to have 'Reset Colors' reset all colors that a theme may have set. Especially when a lot of themes don't reset this themselves.