yes, we no longer support symlinks outside of packages for security reasons. symlinks inside the same package is just fine.

what is the use case for symlinks outside the package in your scenario? (i mean, other than "because i want to" ;)

(In reply to comment #1)
> yes, we no longer support symlinks outside of packages for security reasons.
> symlinks inside the same package is just fine.
> 
> what is the use case for symlinks outside the package in your scenario? (i
> mean, other than "because i want to" ;)
> 

We share common wallpapers with Gnome (and others DE) in Fedora 10 - it saves space, it's easier to maintain - one package for whole Fedora. So just pragmatic reasons.

Thanks for the clarification, we'll work to find an alternative solution not relying on symlinks.

one possibility we do have is to have a flag in Plasma::Package that sets whether or not symlinks outside the package are ok. this would depend on package type, obviously. it would be insane to allow packages with executable code in them to "escape" their package, but it might make sense for read situations like wallpapers or themes where it is just read-only image data.

that's why i asked about the use case. it would be more code, but nothing crazy and could be done for 4.3 quite easily.

but as with any feature addition, it needs justification.

so .. how much does it save you exactly, having symlinkable wallpapers?

Seems Jaroslav will be working on a long term solution to add support for gnome-style wallpaper themes.  *cross fingers*.

In the short term, we'll likely try something like as you suggest, relaxing security for certain types of content, per
https://bugzilla.redhat.com/show_bug.cgi?id=479991#c5

Else, repackaging things to play by the new rules (and possibly use hardlinks) is an option.

>  add support for gnome-style wallpaper themes

shouldn't be too hard ..

> we'll likely try something like as you suggest

ok, this won't be in 4.2 though ... it's a bit late for that.. sorry =(

SVN commit 911736 by aseigo:

allow package structures to say that external paths are ok. defaults to false, though some packagestructures that do not have executable code capabilities (e.g. wallpaper image sets) may wish to take advantage of this
CCBUG:180716


 M  +8 -0      package.cpp  
 M  +18 -4     packagestructure.cpp  
 M  +13 -0     packagestructure.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=911736

SVN commit 911737 by aseigo:

allow external paths in wallpaper image sets.
BUG:180716


 M  +8 -7      backgroundpackage.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=911737

Rex, i think this one is safe enough to backport to your 4.2 packages if you wish. i'm a little hesitant to do it for the upstream 4.2 branch just because it's sort of a "new feature" and not really something that's so critical/common that there's a large clammoring for it.

Hi Aaron,
thanks for your response and patch! Well, we are going to backport it to our 4.2 packages, we hope there will be a lot of time to test it. It really helps us for Fedora 10 - reorganization of wallpapers packages would by difficult and once we arranged cooperation with art team to have one common one for both DEs. For Fedora 11 would be long term solution to support Gnome's backgrounds as said Rex.

if you end up with questions on how best to do that, just ask. i think the easiest approach is to write another PackageStructure subclass and add it to the existing image plugin.

with just that one class, and the right prefixes to look in, it should all just work out of the box.

(In reply to comment #11)
> if you end up with questions on how best to do that, just ask. i think the
> easiest approach is to write another PackageStructure subclass and add it to
> the existing image plugin.
> 
> with just that one class, and the right prefixes to look in, it should all just
> work out of the box.
> 

Actually I'd like to implement it completely, so it will be more complicated. There can be XML definition of slideshow in backgrounds package - in Fedora/Gnome it's used to change wallpaper depending on daytime even with transitions.
So what's currently missing in Image wallpaper service:
1. loading of gnome backgrounds "package"
2. delay for each slide
3. transitions between slides

I think 2. & 3. are worth to implement for KDE too, so this XML can be in Plasma native package.

The XML description looks like this:
<background>                                                                                                                    
  <starttime>                                                                                                                   
    <year>2008</year>                                                                                                           
    <month>10</month>                                                                                                           
    <day>13</day>                                                                                                               
    <hour>07</hour>                                                                                                             
    <minute>00</minute>                                                                                                         
    <second>00</second>                                                                                                         
  </starttime>                                                                                                                  
<!-- This animation will start at 7 AM. -->                                                                                     

<!-- We start with sunrise at 7 AM. It will remain up for 1 hour. -->
<static>                                                             
<duration>3600.0</duration>                                          
<file>                                                               
        <!-- Wide 16:10 -->                                          
        <size width="1680" height="1050">/usr/share/backgrounds/solar/wide/1680x1050/solar-0-morn.png</size>
        <!-- Standard 4:3 -->                                                                               
        <size width="1600" height="1200">/usr/share/backgrounds/solar/standard/1600x1200/solar-0-morn.png</size>
</file>                                                                                                         
</static>                                                                                                       

<!-- Sunrise starts to transition to day at 8 AM. The transition lasts for 5 hours, ending at 1 PM. -->
<transition type="overlay">                                                                            
<duration>18000.0</duration>                                                                           
<from>                                                                                                 
        <size width="1680" height="1050">/usr/share/backgrounds/solar/wide/1680x1050/solar-0-morn.png</size>
        <size width="1600" height="1200">/usr/share/backgrounds/solar/standard/1600x1200/solar-0-morn.png</size>
</from>                                                                                                         
<to>                                                                                                            
        <size width="1680" height="1050">/usr/share/backgrounds/solar/wide/1680x1050/solar-1-noon.png</size>    
        <size width="1600" height="1200">/usr/share/backgrounds/solar/standard/1600x1200/solar-1-noon.png</size>
</to>                                                                                                           
</transition>
...

> 1. loading of gnome backgrounds "package"

right, this is what i was referring to above. this requires one class that describes the package format, nothing more.

> 2. delay for each slide
> 3. transitions between slides

these can be added to the slide show functionality in the image plugin.

> I think 2. & 3. are worth to implement for KDE too, so this XML can be in
> Plasma native package.

can we fix it first? because the xml as used in those packages is pretty .. how to say this politely .. less than what one might expect.

examples:

<starttime>

why is there a year in there? so that one can time it to a future event, such as the presidential inauguration? if so, why no endtime? and what happens if the start year is before the current year? do you just not show the package, or does it not render anything, or...?

and why are there separate tags for each part of the date? holy moly, we have standards for these things, e.g. ISO 8601.

<duration>3600.0</duration>

do we really need fractions of a second? no.

<size width="1680"
height="1050">/usr/share/backgrounds/solar/wide/1680x1050/solar-0-morn.png</size>

absolute paths? wtf?!

<!-- Sunrise starts to transition to day at 8 AM. The transition lasts for 5
hours, ending at 1 PM. -->
<transition type="overlay">             
<duration>18000.0</duration>

so here we have transitions that are supposed to be timed with external events. except that in this exciting world, we have to do this with offsets in seconds from the declared start time. which means to figure out what is going on you have to keep referencing past items in the file. ergo the comments. when you have to comment on things this simple, the API is a Fail.

<from>                                                                          
        <size width="1680"
height="1050">/usr/share/backgrounds/solar/wide/1680x1050/solar-0-morn.png</size>
        <size width="1600"
height="1200">/usr/share/backgrounds/solar/standard/1600x1200/solar-0-morn.png</size>
</from>          

now haven't we seen those entries before? oh, right! they were in the *PREVIOUS ENTRY!*

duplication == brittleness.

in short, this format is braindamaged. and while i'm happy to support it so that we can be compatible with others and continue Plasma's katamari'ing of the rest of the world, i'm dead set against using this kind of crap as native Plasma technology.

here's how it could be done so that it isn't stupid:

forget about start time. just assume a start time of Jan 1 at midnight (01-01 00:00).

define the wallpaper elements, and use relative paths. so:

<images>
<file id="first"><size width="x" height="y">relative/path.png</size><file>
<file id="second"><size width="x" height="y">relative/path2.png</size><file>
</images>

then define timings and transitions:

<display>
<transition mode="fade" start=ISO 8601 compliant date/time from="first" to="second">
</display>

on parsing, you build a list of papers and map them to their IDs; then you parse out the transitions and sort them by date (*gasp!*). the transitions refer to the papers by their ID (first, second, etc. in the example above).

no ambiguities, smaller XML files, relocatable packages, harder to screw up (e.g. by forgetting to change the name/path of files in all the places it appears, since there is now just one entry per file) and a lot more sensible in what it's doing.

you could make it "more XMLish" by breaking out the transitions into multiple tags if you want:

<transition>
   <start>date</start>
   <from>first</fromt>
   <to>second</to>
   <effect>fade</effect>
</transition>

i'm sure that if you thought about it some more, even, you could produce even more improvements.

i mean, wouldn't it be *cool* if you could include little javascripts in your package and optionally do:

<transition>
   <start script="true">relative/path/to/script.js</start>

and then you could actually look up the sun rise / sun set / etc times. the script would be run once at first, returning a date. no date == no show, of course.

once the show time is reached, then the script is run again producing the next show date.

another thing one could do is set up "standard rotation times", e.g.:

<display>
  <transition type="rotation>
    <interval>3600</interval>
    <allfiles/>
    <random/>
  </transition>
</display>

this is all really trivial stuff to accomplish, would be completely optional for the wallpaper package creator and would make something worth distributing.

don't just do, but do better! =)