Rockbox Technical Forums
Support and General Use => Theming and Appearance Customization => Topic started by: soap on April 26, 2007, 07:34:51 AM
-
I was thinking we should have a little informal contest...
An "Update all the broken WPSs contest"
Broken WPSs include but are not limited to:
- Ones which never had the proper directory structure in the .zip file
- Ones listed on the wiki which are hosted elsewhere. (Need to move the .zip to Rockbox)
- Ones which are broken since the WPS tokenizer changes.
- Ones which don't mention they need a custom build.
- Ones which need one patch - but say they need "Senab's build", etc. (Let's list what specific patches they need.)
- Ones which haven't been kept up to date in any way-shape-form with changing WPS syntax.
- We should also flag ones with known protected copyrighted graphics, and ones with known open source compatible graphics.
- We should also tag revision dates on all those w/o.
What I need:
- Judges. I can test on Gigabeat, iPod Video and Nano. (I'd rather test on target than sim, unless someone can convince me otherwise.)
- Contestants.
- Prizes. (Or at least ideas for prizes, I'll cough up prizes if need be.)
- Feedback on this silly idea.
-
It's certainly a good idea to fix them, but I don't quite see what the competition element is...
Is it finding them , or fixing them?
-
It's certainly a good idea to fix them, but I don't quite see what the competition element is...
Is it finding them , or fixing them?
Both!
You get one point for finding one error (first post) and one point for fixing one.
-
At least for the Gigabeat, I think that only one author has updated their theme since the wps code changes. I updated the Ajax theme on my player but who is going to update the zip files on the web? If the theme authors don't update the code, who has the authority to update the themes with compliant code?
Tom
-
Well, any theme that actually lists a license tells you whether you can or can't update their code. If they don't list a license, then you can't.
But you CAN remove the themes from the page, or clearly mark that they're broken.
-
Feedback on this silly idea.
I like the idea.
Another thing I'm disliking since quite a while is the fact that we ship several themes with Rockbox that aren't working on all targets. Take the Ipod mini, only a few themes are available, while on the h100 series it's much more. I'd really like to see (and was thinking about working on it myself, once I find time) the shipped themes adjusted so they work on all supported targets. As the license for that themes is clear there shouldn't be a problem (except the time ;-)
-
In addition,
Ensuring the same case is used in the wps name etc. as in the .cfg file
Without this you get a failure to load in sims on linux
Every theme should set a backdrop, if none required, set it to NULL
Every theme should set Foreground and background colours
Every theme should load an iconset - the default if no custom one required
Otherwise when changing themes, you can get unreadable display, in appropriate backdrops and massively oversized icons etc.
Personal thing, all the files Backdrops, WPS's and cfg files should reflect the name of the theme - hate having to try and tidy up, and not being sure which files belong with which theme.
I have made a start on the themes held on rockbox-themes, I always check the layout of the zip file to ensure .rockbox etc, File naming and I have check most of the 'daily build' compatible 240x320x16 files to ensure the dates are displayed correctly and that they actually load in the sim....
-
In addition,
Ensuring the same case is used in the wps name etc. as in the .cfg file
Without this you get a failure to load in sims on linux
Every theme should set a backdrop, if none required, set it to NULL
Every theme should set Foreground and background colours
Every theme should load an iconset - the default if no custom one required
Otherwise when changing themes, you can get unreadable display, in appropriate backdrops and massively oversized icons etc.
Personal thing, all the files Backdrops, WPS's and cfg files should reflect the name of the theme - hate having to try and tidy up, and not being sure which files belong with which theme.
All solid points.
Perhaps tonight I (or someone else (feel free to beat me to it)) should write up a wiki page on "WPS Certification"(or some such phrase) - a minimal standard of good WPS practices you can use as a checklist.
-
Great idea Soap, good point about the icons RedBreva, I'm done with my exams now so I can give some of the 320x240 WPS's a go, and maybe the 240x320's (as I now have a shiny new gigabeat ;) )
-
I will say, I don't think resetting to the original iconset is mandatory.
If I find an iconset I like (say a 12x12 one that'll fit many themes), it would be extremely frustrating to have to re-set the icon-set on every theme change.
When you pick a theme using too small a font for your iconset, the icons just overlap, and you can very easily pick a new one, but I think on average themes tend to use fonts in a near enough range that forcing a resetting of icons every single time is perhaps not ideal.
-
Every theme should set a backdrop, if none required, set it to NULL
Every theme should set Foreground and background colours
Every theme should load an iconset - the default if no custom one required
I was preparing a reply exactly to talk about this. So, was done. Good Redbreva!
Also, there are WPS themes included on the build with these faults.
Good idea, soap!
♪
-
How about we display a notice that all future submitted WPS files are subject to modification for compliant behavior?
-
How about we display a notice that all future submitted WPS files are subject to modification for compliant behavior?
Maybe we create a cute little "badge" jpg we add to the wiki for all "compliant" WPSs? ie we don't force anything, but acknowledge those WPSs which "go above and beyond the call of duty."
-
Well there's often been talk of moving from a wiki to a site that requires submissions in a particular format, but it's never happened yet. Rockbox-themes.org came out of that, but somehow didn't line up with becoming official.
-
Well, any theme that actually lists a license tells you whether you can or can't update their code. If they don't list a license, then you can't.
I thought there was an assumption if there was no license mentioned it was given as a gift to Rockbox, and thus GPL'd?
No? Poop.
-
Unfortunately we can't assume that, and we don't have that posted anywhere.
The best bet may to be to create a "BrokenWPS" wiki page, and just dump every single one that doesn't work there. They're not deleted, but they aren't in the good lists.
-
Ok then, on top of everything else, to get the "Soap Seal of Approval" a WPS should have an open source license.
;)
-
I will say, I don't think resetting to the original iconset is mandatory.
If I find an iconset I like (say a 12x12 one that'll fit many themes), it would be extremely frustrating to have to re-set the icon-set on every theme change.
But if your favoured iconset is white, and a theme with a white background loads... Â At the very least a white or black iconset should be loaded with every theme - to ensure that they remain visible.
I feel that the icons, now that feature is available, should be 'part' of the theme, isn't it similar to themes switching off the status bar?
You are after all selecting a Theme, if you only want the WPS, for example, browse WPS and only load that, if you only want the backdrop, browse and load that...?? Â
I would even go so far as to suggest that the Theme loading mechanism reset backdrops, statusbars, iconsets, fore/background colours to your configured prefernces before loading the theme... then the theme writer does not need to remember to reset anything he/she is not changing...
BTW, I also like the current trend to include a copy of the required font in the theme zip, even when it is in the font pack... should minimise a number of failures when the user missed the fact that they needed to download them...
-
If your favorite set is white, and suddenly if vanishes, you don't lose any real functionality. Meanwhile, a theme resetting the icons to default because they don't include an iconset (which the majority won't for quite some time) is very frustrating. You'll have to set your theme twice, every time.
The theme loading mechanism should NOT reset anything automatically, EVER. This completely removes the ability to mix and match themes.
I personally like to load a .wps file, a font, and an iconset separately. You're saying that we should mandate that users cannot change their iconset after loading a theme, without resetting the theme.
-
I personally like to load a .wps file, a font, and an iconset separately. You're saying that we should mandate that users cannot change their iconset after loading a theme, without resetting the theme.
No, I am saying that a theme is a complete set of components as decided by a theme author to maintain a consistent look and feel to their creation. That would only kick in if you browsed and loaded a theme. If you just wanted to use a WPS that was supplied as part of a theme, you would browse WPS's and load that part of the theme only, etc... this would prevent accidental theme mismatch where a theme author had missed setting correct colours etc.
I would even go so far as to suggest that the Theme loading mechanism reset backdrops, statusbars, iconsets, fore/background colours to your configured prefernces before loading the theme...
In fact I said that 'your configured preferences' (spelling mistakes apart) - so if you have a prefered iconset for example and loaded a new theme to try it, it had a different iconset, you then loaded another theme with no iconset as part of the theme - your prefered iconset would be re-loaded (from your .cfg file)
In the long run it would ensure that the best themes were fully configured, and that less accurately specified themes would be corrected or abandoned.
I wouldn't want anyone to lose flexibility here, only make it a more consistent and reliable experience for new users. Experienced users can recover from black text on black background etc, and would probably modify the theme file to create their own mix and match compositions. New users trying a couple of themes after just loading rockbox would not...
I have no axe to grind either way on this as I haven't changed the 'theme' on either of my boxes since day one - except for bugfixes - but think it could be more 'consumer friendly' than it is at present... :-\
-
Your statement shows a complete misunderstanding of how .cfg files work.
They're all treated the same (themes, iconsets, standard cfgs, equalizer presets), they're all *just* config files. Your requirement means distinguishing some way between whether a .cfg is a theme, an eq preset, or otherwise, or distinguishing as to whether a setting should be reset if not present, or left the same if not present. Both of which break how .cfg files work presently. Loading things from a preferred .cfg file when they're not present is somewhat silly: Every time someone clicked on an equalizer presets, it'd reset every other setting to the preferred one. And if you say "only with themes", you're forcing people to use the "Browse themes" option, or otherwise designate a theme WPS: What about those of us who switch themes for in-car use but choose a very limited theme that only changes certain aspects of the view (font and color, perhaps, not even WPS?).
I think any theme that changes the text color should also change the backdrop or background, and any theme that does *not* change the text color should reset it to the default (manually), but this should never be enforced in code, because it prevents the use of flexible .cfg files. Instead it should be enforced in themes.
But what does "black on black" have to do with iconsets? Why on Earth should a theme force a reset of iconsets to the default, just because?
I can see perhaps a default iconset being chosen if the new font height is less than the iconset height, MAYBE, but I don't see resetting the icon set every single time a theme is changed as a valid option.
-
Llorean, I'm starting to agree to your way of thinking on this whole icons issue. In summary are you saying that if a theme has a specific iconset for the theme it should set and if there is no iconset for the theme, the cfg should leave the icons alone. After all this discussion I think that makes the most sense.
-
I have made a start on a Wikipage to sum up these notes
http://www.rockbox.org/twiki/bin/view/Main/ThemeGuidelines
Feel free to amend and expand...
-
just wondering if anyone was still interested in this? I'm currently in the process of acting on my plans to reorganize the WPS gallery (mainly the iPod 5G), and I was thinking of doing a mass round of debugging after I was done (depending on how much effort I exert on reorganizing)