FYI, the wallpaper is served up by SetupWallpaper, which is not a Fab4-specific applet. On this we'll have to pay attention to proper support for Fab4 as well as controller (and desktop, and future products)

I think there are two issues here:

1.  Handling platform specific rendering, which has more to do with screen size than anything else and dealing with stretching vs tiling, etc.  Code.

2.  Building device-specific firmware images that include the appropriate wallpaper graphics resources for the given target.   Build environment.

I'll look at the platform build issue. We should also remove move wallpapers from the firmware, with all the additional wallpapers install from SC/SN.

*** Bug 11204 has been marked as a duplicate of this bug. ***

This is fixed in r5855. Gory details below.


Author: bklaas
Date: Fri May 22 21:32:56 2009
New Revision: 5855

Log:
Bug: 11164
Description: achieve platform-specific wallpaper sets by creating share/applets/SetupWallpaper/wallpaper directory in
platform specific source areas and leaving applet code itself in squeezeplay/ area. SetupWallpaperApplet.lua removes hard-coded wallpaper table and replaces it with a dynamic reading of the wallpaper/ directory in the applet path.

solid color wallpaper and images that tile well are still in squeezeplay/
240x320 wallpapers are in squeezeplay_jive/
480x272 wallpapers are in squeezeplay_fab4/
jive and fab4 wallpapers are both currently copied to squeezeplay_desktop/ so they are all available on the desktop, which can choose any of these skins

strings.txt file in squeezeplay/ is "monolithic", in that it contains string translations for all wallpaper titles, no matter what the platform. Token naming convention is PLATFORM_WALLPAPERNAME, which must map directly to wallpapers/platform_wallpapername.(gif|jpg|png)

import new fab4-specific wallpapers from Noah

Any way to make the strings file not monolithic?

To be clearer: I think that we should be able to add a new group of wallpapers to one or more platforms and have the strings tied to the wallpapers, not necessarily centrally managed.

This implies to me that we need to be able to load more than one strings.txt file per applet (i.e. treat strings like data and not like code)

Is this still in the works?  There are a number of wallpapers on fab4 that are carry overs from Controller.  Please keep in mind that Fab4 was not designed to support these wallpapers and these should be removed.

Noah, which wallpapers?

IMO, this is feature complete.

If it is not:

1. wallpaper_allegro
2. wallpaper_encore
3. wallpaper_harmony
4. wallpaper_nocturne (DEFAULT)
5. wallpaper_quartet
6. wallpaper_sonata
7. wallpaper_symphony
8. wallpaper_vibrato

It should be removed.  My fab4 unit is locked or I would call-out the specific images...

so not even solid colors?

I'd left all images that tiled well as platform-inspecific. Those aren't acceptable options for Fab4?

Yes, even the solid colors.  We can add these back to mysqueezebox.com, however, they should not be included in the out-of-box.

disagree, but fine. I'll make the change.

done, r5910

Thanks, Ben.  Let's get back to basics for Jive, Fab4 and Baby and then
review what we have and see where we need to make additions.

On Wed, May 27, 2009 at 1:50 PM, <bugs@bugs.slimdevices.com> wrote:

> https://bugs-archive.lyrion.org/show_bug.cgi?id=11164
>
>
> Ben Klaas <bklaas@slimdevices.com> changed:
>
>           What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>              Status|REOPENED                    |RESOLVED
>         Resolution|                            |FIXED
>
>
>
>
> --- Comment #14 from Ben Klaas <bklaas@slimdevices.com>  2009-05-27
> 13:50:02 ---
> done, r5910
>
> --
> Configure bugmail: https://bugs-archive.lyrion.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>