Support and General Use > Theming and Appearance Customization

what determines the text colour of the intermediate level menus?

<< < (2/2)

Bilgus:
probably an oversight / bug

Frankenpod:
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?

chris_s:
Hi Frankenpod! I think it's easiest if I respond here to your post from the other thread so that it isn't dragged off-topic too much, haha. Here's what you wrote:


--- Quote from: Frankenpod on March 01, 2021, 04:07:30 PM ---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.)

--- End quote ---

Exactly. A theme (or some other config file) can specify custom filetype colors using a line like this:


--- Code: ---filetype colours: /.rockbox/themes/filename.colours
--- End code ---

and reset it as usual:


--- Code: ---filetype colours: -
--- End code ---


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.

Frankenpod:
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.

chris_s:

--- Quote from: Frankenpod on March 02, 2021, 04:46:43 AM ---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.
--- End quote ---
Happy to be able to contribute anything at all, however small. Plus, I wanted these fixed myself. :D


--- Quote from: Frankenpod on March 02, 2021, 04:46:43 AM ---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
--- End quote ---
I responded directly in that thread again.



--- Quote from: Frankenpod on March 02, 2021, 04:46:43 AM ---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.

--- End quote ---
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.

Navigation

[0] Message Index

[*] Previous page

Go to full version