Right now we have something like:

<background>
  <starttime>NUM</starttime>
  <static>
    <duration>1795.0</duration>
    <file>
      <size width= height=>/usr/share/backgrounds/cosmos/cloud.jpg</size>
    </file>
  </static>
  <transition>
    <duration>5.0</duration>
    <from>/usr/share/pixmaps/backgrounds/cosmos/cloud.jpg</from>
    <to>/usr/share/pixmaps/backgrounds/cosmos/comet.jpg</to>
  </transition>
  ...
</background>

Maybe something like this would work:
<background>
  <starttime>NUM</starttime>
  <dynamic>
    <duration>1795.0</duration>
    <transition>
      <duration>5.0</duration>
    </transition>
    <repeat>[once,forever]</repeat>
    <file>
      <size width="" height="">FILE_URI</size>
    </file>
    <filelist>
      <order>[alpha-ascending,alpha-descending,shuffle]</order>
      <size width="" height="">FILELIST_URI</size>
    </filelist>
  </dynamic>
</background>

Relative URIs should be relative the the xml file so we can support backgrounds in ~/.theme dirs.

Online URIs should be supported.

Filelist URIs should return a list of files.  Different URIs may be used for different image sizes.

Transitions are always from previous to next images.

Shuffle order should attempt to visit each file once in a random order before the dynamic section iteration is complete.

What do you think?

Or on second thought, just:

<background>
  <starttime>NUM</starttime>
  <directory>
    <duration>1795.0</duration>
    <shuffle/>
    <transition>
      <duration>5.0</duration>
    </transition>
    <file>
      <size width="" height="">FILE_URI</size>
    </file>
  </directory>
</background>

where <file> here really means URI.  As long as we generalize file to mean URI we don't need a separate dynamic and static.

Instead of confusing the two <transition> tags:

<background>
  <starttime>
    <year>2009</year>
    <month>08</month>
    <day>04</day>
    <hour>00</hour>
    <minute>00</minute>
    <second>00</second>
  </starttime>
<!-- This animation will start at midnight. -->
  <directory>
    <duration>1795.0</duration>
    <shuffle/>
    <transition_duration>5.0</transition_duration>
    <file>Nature/</file>
  </directory>
</background>

Created attachment 142179 [details] [review]
proof of concept patch

The basic idea here is to have a <directory> slide that dynamically creates a set of slides from a directory.  It first reads the directory, creates <static> slides, orders as necessary, and then inserts <transition> slides.

A few things left to do:
 * Much more error checking
 * File type checks
 * Use an <order> tag instead of <shuffle>
 * Handle <size> tags in <directory>

Created attachment 142289 [details] [review]
updated patch

Fix handling of relative paths.

Created attachment 142352 [details] [review]
updated patch

 * Ignore non-image file types.

I discussed this with Soeren last week and he wanted to do the following instead:

<directory>
  <starttime>NUM</starttime>
  <duration>1795.0</duration>
  <shuffle/>
  <transition_duration>5.0</transition_duration>
  <file>
      <size width="" height="">DIR_URI</size>
  </file>
</directory>

ie. <directory> as a toplevel element.  Which would not be allowed in the same file with:

<background>
  <starttime>NUM</starttime>
  <static>
    <duration>1795.0</duration>
    <file>
      <size width="" height="">FILE_URI</size>
    </file>
  </static>
  <transition>
    <duration>5.0</duration>
    <from>FILE_URI</from>
    <to>FILE_NEXT_URI</to>
  </transition>
  ...
</background>

I've been thinking about it and I'm not sure I like it.  Firstly, it is extremely gross XML.  One of the results of this work will be that the resulting xml files will end up being published to the web via theme packs.  I don't really like the existing format enough to do that.  Perhaps we should take a step back and design the XML format first.

Adding the <directory> element could be justified if you interpret them as two completely separate XML formats with separate toplevel elements. As an implementation detail, they just happen to be parsed by the same piece of code.

I do agree that the existing format is pretty bad in many ways, though, and that a redesign would be good thing.

First, let me start off by saying I really do appreciate what all of the developers do. The following are some observations and thoughts I had when trying to make my own background slideshow.

I've wondered if the XML file is really necessary to have in each wallpaper slideshow? Wouldn't it make more sense to be able to select a directory from the GUI and have duration and transition information configurable from the GUI? This wouldn't add that many extra buttons if a few constraints were made (each image stays on the background for the same period of time). That could even be altered by setting some sort of random % of duration drift. This could also allow adding things like random image order and easily adding images to the background slideshow (just add it to the folder). IMHO, I think this sort of thing would cover 90% of the Gnome users out there. For the other 10%, there could be an override if the XML file is found in the background directory.

If an XML file must be used, couldn't it allow something as simple as

<background>
  <directory>PATH</directory>
<background>

This would also need to have transitions and durations built into the GUI and code rather than specified from the XML file.

Most of what I have seen in the cosmos XML file seems like repetitive unnecessary information that could either be consolidated or removed. Why do we need to manually specify <from> and <to> for each image change. Couldn't this be gathered from the current image and then whatever is next in the list? Doesn't this transition requirement bar any sort of randomization?

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-desktop/issues/28.