Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: post release theme changes - make them more consistent

Re: post release theme changes - make them more consistent

From: Thomas Martitz <thomas.martitz_at_student.htw-berlin.de>
Date: Sat, 23 Jan 2010 17:36:17 +0100

Am 22.01.2010 07:45, schrieb Jonathan Gordon:
> 2010/1/21 Jonathan Gordon<jdgordy_at_gmail.com>:
>
>> This might be controversial, but my mind is pretty made up about this.
>> consistency in skins really is important, I'd need a very logical
>> reason to not go ahead with this.
>>
>> POST 3.5 themes will need to be made more consistent. The current
>> situation is apparently a mess.
>>
>> No settings are being removed, or hidden, or anything. The change is
>> going to be priority between the setting and the skins.
>> The change will make everything align with one simple rule "Use the
>> settings for fallbacks only". What this means is this:
>> If a skin (SBS or WPS for now, FMS and WRS coming soon :p ) specifies
>> a<something> that also exists in a setting, then use the value from
>> the skin, otherwise use the setting.
>> SO:
>> - if a skin sets a backdrop use it, if it doesnt *always* use the
>> setting backdrop (the sbs backdrop will never be shown in any other
>> skinned screen unless of course they both specify the same filename)
>> - if a viewport in a skin uses - for colours, then use the setting
>> (this is svn behaviour and wont change)
>> - (sbs only) if the sbs specifies a %Vi then use it completely, if it
>> doesn't then use the one from settings (unlike svn where the UI area
>> is the intersection between the 2)
>> - %we/wd in skins then is also consistent (both ignore the setting)
>>
>> The arguments against this are basically "I like this theme but want
>> to tweak it" in which case I can only say go for it, but you need to
>> change the actual skin files instead of your .cfg.
>>
>> Jonathan
>>
>>
> FS#10922 is the patch which implements this
>

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.
Received on 2010-01-23


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa