Support and General Use > Theming and Appearance Customization
WPS image idear
amiconn:
--- Quote from: kenshin on October 24, 2005, 12:25:57 PM ---The best solution, as Daniel proposed, would be to make the files load from the same directory as the WPS file. That way we need no major WPS changes nor do we get locked into anything in particular. Everyone can keep their files in subdirs of .rockbox (I've wanted this for awhile, myself). If no one submits a patch for this in the next couple weeks I'll do it. I can't this week or next as I'll be on vacation and business travel.
--- End quote ---
I don't think this would be a good solution. The settings system only remembers the .wps if it's located directly in /.rockbox, not if it's in a sub-directory or elsewhere. This is for a reason - to save space in the settings sector. So if the .wps code would load the associated .bmp files from the .wps's dir, they would still clutter /.rockbox.
I can think of two possible solutions:
* Let the code load the .bmp files from a sub-dir of the .wps dir which is named the same as the .wps, but without extension, i.e "test1.wps" would load its images from "test1/"
* My old idea - allow multiple images in one .bmp file. The .bmp would be loaded once, then the various snippets can be displayed by specifying the region in pixels.
There are 2 possible extensions for idea #2:
* In order to reduce code size, allow only one .bmp per .wps
* When doing this, we could go even further and derive the name of the .bmp from the .wps, i.e. "test1.bmp" would be the image container for "test1.wps"
Just my € 0.02
ceebmoj:
%x|a|a.bmp|0|0|
%xl|m|l.bmp|41|1|
%xl|n|m.bmp|41|1|
%xl|o|n.bmp|41|1|
%xl|q|o.bmp|6|12|
%xl|r|p.bmp|6|12|
%xl|s|q.bmp|6|12|
%xl|t|r.bmp|6|12|
%xl|u|s.bmp|26|1|
%xl|v|t.bmp|73|0|
%xl|x|u.bmp|81|0|
%xl|B|b.bmp|0|0|
%xl|C|c.bmp|0|0|
%xl|D|d.bmp|0|0|
%xl|E|e.bmp|0|0|
%xl|F|f.bmp|0|0|
%xl|G|g.bmp|0|0|
%xl|H|h.bmp|0|0|
%xl|I|i.bmp|0|0|
%xl|K|j.bmp|0|0|
%xl|L|k.bmp|0|0|
%xl|O|v.bmp|112|0|
%xl|P|w.bmp|112|0|
%xl|Q|x.bmp|112|0|
%xl|R|y.bmp|112|0|
%xl|S|z.bmp|112|0|
%xl|T|aa.bmp|111|0|
%ac%?it<%it|%fn>
%ac%?ia<%ia|%d2>
%ar%pc/%pt
%fbk %?fc<MP1|MP2|MP3|WAV|OGG|FLAC|MPC||WPK|>
%?pv<%xdB|%xdC|%xdD|%xdE|%xdF|%xdG|%xdH|%xdI|%xdK|%xdL>
%?bp<%xdT|%?bl<%xdO|%xdP|%xdQ|%xdR|%xdS>>
%?mm<|%xdm|%xdn|%xdo>
%?mp<|%xdq|%xdr|%xds|%xdt>
%?ps<%xdu|>
%?mh<%xdv|>
%?mr<%xdx|>
I got this wps from the mystic river sight the wps is by the_engineer looking at it the vast majority of the wps is concerned with loading the bmps and associating them with tags.
I am not sure what is the best way to implemented it but there must be a more efficient way than this. My idea was to use a c, like loop
%xl|img[]|.bmp
where the image files are loaded in the order they occur in the file system or they could be numbered. There are a number problems n this now I come to try and explain it to you.
However the point remains that there is scope to improve the system as the majority of the wps should not be taken up preloading images
kenshin:
--- Quote from: amiconn on October 24, 2005, 02:13:03 PM ---
--- Quote from: kenshin on October 24, 2005, 12:25:57 PM ---The best solution, as Daniel proposed, would be to make the files load from the same directory as the WPS file. That way we need no major WPS changes nor do we get locked into anything in particular. Everyone can keep their files in subdirs of .rockbox (I've wanted this for awhile, myself). If no one submits a patch for this in the next couple weeks I'll do it. I can't this week or next as I'll be on vacation and business travel.
--- End quote ---
I don't think this would be a good solution. The settings system only remembers the .wps if it's located directly in /.rockbox, not if it's in a sub-directory or elsewhere. This is for a reason - to save space in the settings sector. So if the .wps code would load the associated .bmp files from the .wps's dir, they would still clutter /.rockbox.
--- End quote ---
I had thought of this but I wasn't aware of the reasoning behind it. My only thought on how to make it work involved changing the settings to refer to wps1/file.wps instead of just file.wps. Maybe that's not a good approach if space is why it's required to be in .rockbox as it currently is.
--- Quote from: amiconn on October 24, 2005, 02:13:03 PM ---I can think of two possible solutions:
* Let the code load the .bmp files from a sub-dir of the .wps dir which is named the same as the .wps, but without extension, i.e "test1.wps" would load its images from "test1/"
* My old idea - allow multiple images in one .bmp file. The .bmp would be loaded once, then the various snippets can be displayed by specifying the region in pixels.
--- End quote ---
Given the choice between these two I'd vote for #1. It cleans up the filesystem but doesn't harm the size and complexity of a WPS. And it would be a pretty simple change. Putting all the images into a single .bmp would certainly increase the complexity. Some people already have difficulty with "%xl|a|file.bmp|x|y|" and "%xd|a|".
ray:
--- Quote from: kenshin on October 24, 2005, 12:25:57 PM ---The best solution, as Daniel proposed, would be to make the files load from the same directory as the WPS file. That way we need no major WPS changes nor do we get locked into anything in particular. Everyone can keep their files in subdirs of .rockbox (I've wanted this for awhile, myself). If no one submits a patch for this in the next couple weeks I'll do it. I can't this week or next as I'll be on vacation and business travel.
--- End quote ---
this is similar in vain to the way winamp used to select its skins before they introduced archive support (although winamp had a directory specifically for skins)... the solution proposed by Daniel seems to be the best one right now.
although i would like to see a fixed directory similar to winamp's titled "WPS" or something along those lines, then you can either add all WPS' into the fixed folder or do something like this:
x:\.rockbox\WPS\skin1\
x:\.rockbox\WPS\skin2\
that way WPS' which use the same filename for BMPs will not interfere with another WPS design.
Navigation
[0] Message Index
[*] Previous page
Go to full version