Organizing the wiki page:WpsIpod5g

[lights0ut]

Over the course of my time on the forums here, it seems like there are a large majority of users that do not
read the words "this theme requires  a patched rockbox build: link to specific build" and then complain about a specific theme not working in the forums.
The wiki (especially the iPod 5G) is just a list of themes, maybe there should be efforts made to divide it into two sections :
1.Compatible with the current build
2.Requires patches/ custom build

With a quick explanation of what each option means for the users who remain oblivious.
I'd recommend organizing further because most WPS's that require a patches/custom build usually only need
Album Art and Scrolling Margins, so maybe a section for those, and then a section for everything else underneath the Requires Patches section.
While I'm at it I might as well flag the themes as either "soap certified" or not (see this thread).

I'm not asking someone to take the time to do this, I'm willing to commit a few hours to it, I just want to see the feasability of the idea.

[bascule]

I think just separating custom build or not is sufficient; perhaps augmented with clearer indication of which build and/or patches are required

[psycho_maniac]

Or just remove them from the wiki as they are not supported by rockbox and the developers  anyways.

[lights0ut]

Psycho_maniac, not everyone can obtain hosting for their themes, and while removing the unsupported ones would greatly simplify things, I don't think this is necessary. Many users want to enjoy album art/scrolling margins features, and as a result there have been many WPS's made with those patches. The builds needed for them are easily obtainable too. Why would separating/ catagorizing the WPS's not be enough?

[bluebrother]

Psycho_maniac, not everyone can obtain hosting for their themes

There are plenty of free hosting services around so I think this could be considerated.

[bascule]

There are plenty of free hosting services around so I think this could be considerated.

Yes, but they are mostly rubbish and/or full of spammy adverts.

As the custom builds are hosted, I see absolutely no reason why custon WPS's should not also be hosted.

[Nate!]

Just my two cents:  I agree with Bascule:

As the custom builds are hosted, I see absolutely no reason why custon WPS's should not also be hosted.

I know there are minimalists that use rockbox, to each his own.  But, Custom WPSs are a sought-after feature.  Since custom builds are hosted, WPS that are created for those builds should be hosted also.

EvilG's idea of organization is great.  Sort of like the rockbox-themes page, except maybe clearly define in bold that a specific build/patch is needed.

I guess, since it is a wiki, EvilG can make the changes.  If there are any objections, the Admins can roll back to the previous revision.

Maybe sections like:

Official build customs:
  The following WPSs will display correctly using the official build rxxxxx-Date.

WPS.wps

EvilG Fusion/J build:
  The following WPSs will not display correctly unless you download the current x build.

Senab build:
  The following WPSs will not display correctly unless you download the current x build.

[Llorean]

We could just stop hosting custom builds.

[bluebrother]

We could just stop hosting custom builds.

Where do we host custom builds? I only know about the forum threads, and those link to external sites that hold the custom builds itself.

Or did I miss something here?

[soap]

EvilG Fusion/J build:
 Â The following WPSs will not display correctly unless you download the current x build.

Senab build:
 Â The following WPSs will not display correctly unless you download the current x build.

No.
This is part of what we need to move away from.
There is no WPS out there which relies on the brightness patch from Senab's build.
There are not WPSs out there which rely on the one click to insert, plugin backlight always on, or random album select patchs from evilG's build.
We should not be associating WPSs with builds, but rather with features.  Features which may or may not be part of "stock" Rockbox by the time some future gallery visitor is reading the WPS description.

[Nate!]

Where do we host custom builds?

Just quickly browsing to the Gigabeat gallery, there are unofficial builds attached as well as the WPS "package."

I've seen this in the 320x240 gallery also.

zips attached, not builds linked to an external sites.

We should not be associating WPSs with builds, but rather with features.

Good Point.  Features, should we only list patches that a specific unofficial build will need in order for the WPS to work?

X WPS
  * needs Album Art and Scroll Margins patch in order to view as shown.

or

X WPS
   * Able to support Album Art and Margins for scrolling text.

The latter may lead some to believe that downloading the WPS and loading it on an official build will subsequently "enable" those features. No?

The Galleries need organizing.  Someone has volunteered to start it.  Suggestions on how it should be done are what he's asking for.  
I hope no one takes the above as being rude, they're really just light harded assessments of the original post.

Let's face it, people like the cool features and looks of the WPSs that artists and the like put there time and effort into creating.  They want to share their work with the Rockbox community.  That's what the wiki/gallery is for.  Organizing it into a more user friendly and intuitive format is a good idea.

[lights0ut]

Would it be a good idea to physically separate the themes that work on the current build from the themes that work only on unsupported builds? (i.e. separate galleries)

I was just thinking that the TOC section of the Wiki would be more useful that way because with one combined gallery there will be this:

Themes that work with current build
...........
..........
.........

and then in the middle of all this

Themes that work only with unsupported builds

etc.
.

Come to think of it now, I could just use an HTML link instead of the the wiki's TOC so it would be:
current build                  unsupported

TOC

[Llorean]

Any unsupported builds actually attached to the wiki need to be removed. Please point out where they are so that I can see to it this happens.

[scorche]

I was thinking of going with the SOAP seal with different colored icons denoting WPSs that will work with SVN builds versus ones that require patches.

Regardless, I plan on having this topic be one of the topics discussed in DevCon-West.

[Domonoky]

One thing i really would like to see, is the integration of rockbox-themes.org, because rbutil (the future official rockbox utility) can now install Themes from this site.
This is not possible with the wiki.
So it would be really good, if, atleast, the Themes which dont requiere custom build are aviable via this site, or something similar.