Rockbox mail archiveSubject: Re: post release theme changes - make them more consistent
Re: post release theme changes - make them more consistent
From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Sat, 23 Jan 2010 19:01:24 -0800
2010/1/23 Thomas Martitz <thomas.martitz_at_student.htw-berlin.de>:>
> What's the point of a backdrop setting if the sbs can specify one? I don't
> really see the need for it anymore. Loading a backrop from the filebrowser
> can easily replace the sbs one's without even reparsing the sbs. And if
> there's no sbs loaded, then having a backdrop is as simple as settng up a
> in-RAM sbs with only the %X line (moving the backdrop to the skin buffer
> while still maintaining the old setting costs a lot of RAM). And once
> there's no backdrop setting, the UI viewport setting is also rendered
> useless (especially considering your plans to make it a fall-back thing).
> Best regards.
EXACTLY! which is what I was arguing a while back and got yelled down
My latest patch (FS#10922) does almost exactly that. if no sbs is
loaded then an in-ram one is created from the backdrop, statusbar and
ui viewport settings.
The last issues that need to be sorted out is how to handle backdrops
so it makes sense with "use settings as fallback". What I'm thinking
is %X|-| will use the setting (so the same as viewport colours) and
having no %X means dont use any backdrop. OR %Xd would make sure the
backdrop is never shown and having no %X means use the setting
instead. the second is closer to svn's behaviour so is probably more
Now, loading a clearing backkdrops from the file browser and menu gets
interesting. if a sbs specifies a backdrop it will right now (in the
patch that is) be always overwritten with the new backdrop untill the
theme is reloaded, same with clearing. I tihnk this is probably
acceptable because the point of loading the backdrop is to see how it
would look in the theme, if its actually wanted then you need to
fiddle with the .sbs.
Received on 2010-01-24