Rockbox

Tasklist

FS#4885 - different/additional directory for WPS bitmaps

Attached to Project: Rockbox
Opened by Matthias Mohr (aka Massa) (mmohr) - Wednesday, 22 March 2006, 13:27 GMT
Task Type Feature Requests
Category Themes
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

Just have an idea which could sometimes help to make "light WPS packages", that means only the WPS file without the bitmaps.
I think there are a lot WPS outside which use the same bitmaps as another WPS (e.g. v0.9 of a WPS and v1.0 or a derivate).

Currently you have to copy and rename the bitmap folder for that so that it matches your choosen WPS name.
Why don't add a special WPS tag which tells in which subdirectory the bitmaps will be searched?
If it's not present, it'll search the bitmaps in the subdirectory with same name as the WPS (as it is done today).
But if such a tag is present, it'll search the bitmaps in the subdirectory with same name as WPS first and if it could not find it there it'll have a look in that given bitmap directory.

With that mechanism we could easily make derivates of WPS which only contains the changes to the original one.
The bitmaps don't have to be copied several times - only the different ones...

What do you think?
Would it make sense for somebody else?
This task depends upon

Closed by  Bj√∂rn Stenberg (zagor)

Reason for closing:  Fixed
Additional comments about closing:  Closing all feature requests.
Comment by ApooMaha (crzyboyster) - Monday, 31 March 2008, 22:29 GMT
My explanation:


I think that if a .wps file can be linked to a wps image folder with a different name than that of the wps file would be a great idea.

(I think I confused people there, so here's a more simple explanation)

x.wps file can use the images in the "y" image folder or any other image folder, for example.

Right now, the x.wps file has to use the images in the "x" image folder in the wps directory.

Adding this capability will allow theme authors to make different themes with just the background changed and have no need to make two of the same image folders with the same images except for the background image (get what I'm saying?) and it would be pretty convenient for the cabbiev2 unifont downloads so that just the .wps and .cfg files would have to be put up for download.

Another thing that might be nice would be that if you could decide which wps folder each specific bitmap points to (exact path /wps folder/bitmap.bmp)

It would probably save space on people's hardrives too and make theme packs easier to handle (better for the new rockbox-themes.org site?)


Only real problem is themes breaking if another theme is deleted.
Comment by Linus Nielsen Feltzing (linusnielsen) - Tuesday, 01 April 2008, 06:16 GMT
I think adding such dependencies between themes is a really bad idea. And does a theme really take that much disk space?
Comment by ApooMaha (crzyboyster) - Tuesday, 01 April 2008, 20:10 GMT
No...

But the many benefits of this should outweigh the problems (atleast from what I understand)

So let's get this straight though: The only real problem is inter-theme dependency, right?

If that is the only problem, that should be OK and it would become a part of rockbox usage.

Theme packs and such (even cabbiev2 unifont) can use this easily and the wps folders should be named such that users won't delete them thinking about getting rid of one theme.

Example:

acotil_blue.wps would link to "acotil" wps image folder and all of the different wps backgrounds, images, etc. for the acotil theme pack would be found in the "acotil" wps image folder.(Sounds better than how theme packs are done right now)

This would also allow you to change certain images once in the folder that are used in all of the themes in the pack and allow the changes to be seen in all of them.

Example:

progress.bmp used in all of the acotil themes in the pack can be modified once (if same bitmap used throughout all) and changes would be seen throughout all versions.

Loading...