Support and General Use > Theming and Appearance Customization

Themes Broken with 3.7: Syntax change?

<< < (4/4)

[Saint]:

--- Quote from: Bockrox on January 06, 2011, 04:20:04 PM ---I agree that theme developers were given ample warning about the changes.

--- End quote ---

Perhaps I am reading too much into it this seems to suggest that while you're willing to believe that developers were given ample notice, you still seem to think that users were not.

However, I can see this just going around in circles.


I know of numerous people that created themes based on the new skin syntax well before it entered a tagged release build.

A great many of those people I helped personally in understanding issues with conversion from old and new tags, and most if not all of those people were "Joe Average" users.

Another thing I feel I should mention is the huge amount of effort the Rockbox team went to to make sure that the skin breaking changes were integrated as smoothly as possible into the core.

Before the skin breaking changes were released the entire theme site was backed up so that users who were using an (at the time) current release build could still use the themes they wanted, and a new (the now current) theme site was created from a clone of the old one and all the themes in it were batch updated so that they were compatible with the new (current) skin syntax in preparation for the release and so that people using daily builds had access to their favourite themes.

To this date you can still access the original theme site and download "old" themes from there in case you don't want to/can't update to a current/release build for whatever reason..

It really, really, *really* isn't as if the skin syntax was just changed overnight  and the Rockbox team was like "Oh, yeah...it changed. Deal with it".



[St.]

bluebrother:

--- Quote from: Llorean on January 06, 2011, 02:08:14 PM ---A version string wouldn't do any good because that would end up rejecting perfectly compatible themes as well.
--- End quote ---

Indeed, since that would be replacing one problem with another. To give an example: some while back I was using a Firefox extension that became incompatible with updated versions of Firefox. However, the extension itself wasn't incompatible at all, it was just the announced compatibility version, so the "fix" was to edit the xpi and change the version string. I don't think this kind of problem is better than a theme being rejected because it became incompatible.


--- Quote ---As I said earlier, about the only improvement really reasonable is it popping up something to explain when the theme fails to load.
--- End quote ---

That would make sense and I'm in favour of such a notification since quite a while.

[Saint]:

--- Quote from: bluebrother on January 07, 2011, 07:24:24 AM ---
--- Quote from: Llorean on January 06, 2011, 02:08:14 PM ---As I said earlier, about the only improvement really reasonable is it popping up something to explain when the theme fails to load.
--- End quote ---

That would make sense and I'm in favour of such a notification since quite a while.

--- End quote ---


I agree with this personally, but I have to say that I don't really see the point.

The reason why I agree is a little sad, purely for aesthetics. I just think it would be a nice touch, there would be room on most players for a reasonably verbose message:


--- Code: ---<Theme_Name>.<ext_of_failed_file> Failed!
 <some_limited_debugging_output_here>*
         Loading rockbox_failsafe.cfg

--- End code ---
*Debug info: Perhaps the line â„– that failed to parse, or the name(s) of missing font(s)/bitmap(s)

Or something similar...

However, the reason I don't believe it is particularly necessary was covered by Llorean a few posts back and is indeed quite sane when I think about it. That being, that the fact that the failsafe theme loaded (I thought) was clear enough indication that the current theme has failed.

That isn't particularly elegant though, as it doesn't tell you what failed, just that something indeed failed.

I am all for the idea of some (limited) on-target debug output for themes, and I have mentioned it personally in IRC more than once...but I don't believe it is one of the most critical things yet to be implemented in Rockbox ;)

I believe that the perfect time to integrate such a thing would have been prior to, or at the same time as, the inclusion of the skin breaking changes. It might pay to implement some on target debug output still though, for cases like:

- Accidental breakages in the skin engine
- User tries to load a theme for an incorrect target**
- Missing font(s)
- Notice that a very large font is unlikely to display well on players with small screens?***
**I imagine this would be easy to test for in a few ways, some themes would "just work" though.
***Some simple math (if screen_height < <font_height>*<min_list_entries> then, warn)

So, ...yeah. I'm all for a user notification, but I wouldn't suggest that anyone needs to slave over a keyboard for hours on end at a top priority status until it's added. It would be nice to have, but not having it is hardly the end of the world. ;)



[St.]

evilnick:
How about a plugin that could check the .wps files? I don't like the idea of the error-checking being built into the core of Rockbox, for the usual memory constraints/binsize issues.

I'm thinking that if the theme fails, then print the standard "Oops, this theme has failed, please run plugins/checkwps for more help" to screen - then there's a minimal hit.

Llorean:
Yeah, I wasn't suggesting a splash of debug output so much as  simple "Theme has failed to load, using fallback" or "Theme incompatible, run checkwps" (if such a plugin comes to exist).

Navigation

[0] Message Index

[*] Previous page