Pictures folder: --location requires absolute path

Bryce, what's the contents of your ~/.config/user-dirs.dirs file?

You can also use --location=$HOME/Pictures as a workaround, but I'm curious why your pictures directory isn't picked up automatically.

This is with a totally stock ~/.config/user-dirs.dirs (attached anyway).

I've retested this with latest lucid, and while --location=~/Pictures still does work as I think it should, --location=Pictures does work now, as does --location=$HOME/Pictures.

(My real ulterior motivation for this is to be able to set up my folk's computers to share baby photos with them via UbuntuOne, but I'm finding the --location option to be kind of spotty and it isn't working for this purpose. I haven't re-tested UbuntuOne on Lucid but I did just re-test if the photos are on an NFS mount point and it still doesn't seem to read them.)

So, you actually have three issues?

1- Default pictures directory as set by XDG_PICTURES_DIR isn't being used by the screensaver
2- screensaver's --location should accept ~/Pictures
3- screensaver doesn't work with pictures directory specified on an NFS mount point

On Thu, Mar 11, 2010 at 12:59:47AM -0000, Marc Deslauriers wrote:
> So, you actually have three issues?
>
> 1- Default pictures directory as set by XDG_PICTURES_DIR isn't being used by the screensaver
> 2- screensaver's --location should accept ~/Pictures
> 3- screensaver doesn't work with pictures directory specified on an NFS mount point

No, just issues #2 and #3. The default out-of-the-box settings work
fine.

[Expired for gnome-screensaver (Ubuntu Lucid) because there has been no activity for 60 days.]

[Expired for gnome-screensaver (Ubuntu) because there has been no activity for 60 days.]

I don't know how to make a patch but if you change this "if" statement around line 100 in savers/slideshow.c from

if (location != NULL) {
    g_object_set (engine, "images-location", location, NULL);
}

to something like

if (location != NULL) {
    wordexp_t expanded_location;
    wordexp(location, &expanded_location, 0);
    location = expanded_location.we_wordv[0];
    g_object_set (engine, "images-location", location, NULL);
}

and #include <wordexp.h> it will expand ~/Pictures correctly

the correct way to fix this is to have an easy to configure preference for it (googling to edit text files doesn't quite cut it)

which is reported as bug 47604

Rolf, I would say configuration is a separate issue. The bug described here is about the ~ path not getting expanded correctly.