After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 510554 - support multi-resolution background images
support multi-resolution background images
Status: RESOLVED OBSOLETE
Product: gnome-desktop
Classification: Core
Component: libgnome-desktop
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Desktop Maintainers
Desktop Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-01-19 06:29 UTC by Matthias Clasen
Modified: 2008-08-13 03:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
multires.patch (6.57 KB, patch)
2008-01-19 06:30 UTC, Matthias Clasen
none Details | Review
Available sizes (119.46 KB, image/png)
2008-01-19 17:24 UTC, Mark
  Details
multires2.patch (13.28 KB, patch)
2008-02-25 03:29 UTC, Matthias Clasen
none Details | Review
same patch again, this time against the latest sources (10.51 KB, patch)
2008-02-25 04:20 UTC, Matthias Clasen
none Details | Review

Description Matthias Clasen 2008-01-19 06:29:54 UTC
It would be nice if GnomeBg would support multi-resolution images.
Currently, we have to install separate wide, dual-head, etc versions of
the default Fedora background, and they all show up as separate entries in the
background capplet, leaving the user to pick the best one.

Here is a patch that extends Soerens slideshow support to parse files like the 
following:

<background>
  <static>
    <duration>10000</duration>
    <sizes>
      <file width="800" height="600">/home/mclasen/image1.png</file>
      <file width="1600" height="1200">/home/mclasen/image2.png</file>
      <file width="1920" height="1200">/home/mclasen/image3.png</file>
    </sizes>
  </static>
</background>

The file shows up as a single item in the appearance capplet, and the best size is picked, depending on the screen resolution (the algorithm to pick the best
size can probably be improved...)
Comment 1 Matthias Clasen 2008-01-19 06:30:29 UTC
Created attachment 103185 [details] [review]
multires.patch
Comment 2 Vincent Untz 2008-01-19 14:47:07 UTC
Søren: can you review this (and commit if you're fine with this)?
Comment 3 Matthias Clasen 2008-01-19 15:11:53 UTC
One thing to point out here is that it currently won't work to combine multiple resolutions with animation. Maybe we should make that work...
In general, the slideshow parser probably needs some robustness testing.
Comment 4 Mark 2008-01-19 17:24:09 UTC
Created attachment 103205 [details]
Available sizes

"Great to have that functionality in Nautilus!
now i'm wondering if something like this could be implemented for GDM
as well..?? the GDM background for Fedora 8 is a .png image with a
size of: 2560 x 1600 and having that auto adjusting to the user
display size would be wonderful!

or perhaps SVG support in GDM (couldn't both options in gdm's bugzilla)?"

Oke right after i wrote the above i thought of the following case:
What if a user downloaded a wallpaper pack which uses the smart size
stuff that Matthias made? than the user would get the wallpaper that's
suitable for his size.
But what if the user wants (for whatever reason) a different size? i
don't see any option of doing that at the moment.

So i made a nice mockup of the Appearance Preferences -> Background
section and edited in the "Available sizes" option and some example
sizes with a radio button that indicates which one is gonna be used.
The place in that section is available to put it in.

Posted the same on the bugzilla page.
Comment 5 Matthias Clasen 2008-01-19 19:28:57 UTC
The whole point of this feature is to let the computer automatically pick the right size, making the need for manual selection go away. Therefore, I am against adding back complicated selection UI like you propose.

The individual sizes are regular images, so if you really care that much, you can just add them to your selection of available backgrounds using the "Add" button.
Comment 6 Mark 2008-01-19 23:01:47 UTC
Oke that's a possibility.
But is it wrong that the best resolution is checked automatically and than just give the user the option to go with that or choose one of the other resolutions?

That would make this patch simply perfect to me ^_^
Comment 7 Soren Sandmann Pedersen 2008-01-26 19:37:44 UTC
I do think this should be supported for animated wallpapers as well. Unfortunately, there is no obvious way to add multi-resolutions to <transition> elements. 

It's possible that the file format is just not very suitable for extension. Maybe we should fix that while we still have the chance. Fedora, and possibly Mandriva are the only distributions that have shipped it, as far as I know. We could probably deal in Fedora; I doubt there are any third-party backgrounds.
Comment 8 Matthias Clasen 2008-01-26 19:44:41 UTC
yeah, lets do a quick review of the file format before it gets frozen in an unfortunate state. 
Comment 9 Matthias Clasen 2008-01-26 21:50:47 UTC
We could do something like:

<background>
  <static>
    <duration>12345</duration>
    <file>/only/one/size.png</file>
  </static>
  <static>
    <duration>12345</duration>
    <file>
      <size width="400" height="200">/very/small.png</size>
      <size width="400" height="400">/square/one.png</size>
    </file>
  </static>
  <transition type="overlay">
    <duration>12345</duration>
    <file type="start">
      <size width="400" height="200">/very.small.png</size>
      <size width="400" height="400">/square/one.png</size>
    </file>
    <file type="end">/only/one/size/again.png</file>
  </transition>
</background>

Alternatively, we can stay with <from> and <to>, or we can unify the 
elements even more, and merge <static> and <transition> into
<element type="static"> and <element type="overlay">.

One more change that would be beneficial, imo, is to allow
the transition elements to refer implicitly to the files of the
previous and next elements:

 <static>
   <duration>1000</duration>
   <file>image1.png</file>
 </static>
 <transition type="overlay">
   <duration>1000</duration>
 </transition>
 <static>
   <duration>1000</duration>
   <file>image2.png</file>
 </static>

reads much easier than the version that repeats all the file names several times. Adding multiple sizes will only make the repetion worse.
Comment 10 Matthias Clasen 2008-02-25 03:29:24 UTC
Created attachment 105888 [details] [review]
multires2.patch
Comment 11 Matthias Clasen 2008-02-25 03:32:48 UTC
Here is an iteration that supports multires for animations and static images.
The file format is backwards compatible by allowing, at any place where the current format expects a filename, to specify one or more
<size width="w" height="h">filename</size> elements. It is still possible to just specify a filename, if you don't have multiple sizes.
Comment 12 Matthias Clasen 2008-02-25 04:20:39 UTC
Created attachment 105889 [details] [review]
same patch again, this time against the latest sources
Comment 13 Matthias Clasen 2008-08-13 03:48:46 UTC
This has been committed at some point.