You are not logged in.
setroot is a CLI program written in C that sets your (X11) wallpaper. its only dependencies are imlib2. it is inspired/based off imlibsetroot, hsetroot, esetroot, and feh, the traditionally used background setters, and is under GPLv3.
**project page**: github page
setroot - AUR Package
setroot-git - AUR Package (not much difference)
features:
"traditional" wallpaper options (center, stretch, zoom, fit, solid color)
xinerama aware. option to span all screens
image manipulations - flip, sharpen, blur, brighten, contrast, tint color
use-[xy]-geometry: number xinerama monitors from left/right or up/down
installation:
git clone
cd setroot
sudo make install (clean)
If you will permit a little history as to why I wrote this when there are so many others out there already...
1. Used hsetroot for a time, liked the image manipulation features, but lacked the ability to completely fill my screen and preserve aspect.
2. Moved to feh, (which had --bg-fill option!) but had no use for the image viewing capabilities as I already used muennich's excellent sxiv. I wanted a program that set my wallpaper, and did that only.
3. Switched to imlibsetroot, but got odd segfaults, x11 errors, and imlib errors. tried hacking, but code was pain to edit and had a lot of extraneous features I never used.
4. I wanted to learn some C, so I started writing setroot.
I would be very appreciative of anyone who tries this out and gives me feedback on bugs, improvements, coding tips, feature requests, etc. I have no formal programming or software engineering experience, I am just a lowly math major who has discovered the joy of coding, so I will take anything I can get.
Hope some of you find a use for it.
Last edited by ttz (2014-11-14 16:50:27)
Character shines in the great moments, but is polished in the little ones.
Offline
Tried it on i3 and it worked as expected. I like the blur and sharpen effects too. Not sure my testing really helps because I have a very simple set up (one screen) but I wanted to offer some encouragement for a nice app.
Offline
Thank you for testing it and for your encouragement!
Character shines in the great moments, but is polished in the little ones.
Offline
Nice, I was thinking about doing the same for the exact same reasons.
What I don’t like about feh is that it relies “Xinerama order”: First “Xinerama screen” gets the first wallpaper and so on. Just like you do it in setroot. This is totally fine when you only have one screen but I have three screens and—sometimes—their order changes. (I don’t know why exactly.) It would be ultra-nice if setroot had a “--use-geometry” option. When using this option, setroot uses the screens’ position (`x_org` and `y_org` as returned by `XineramaQueryScreens()`) to figure out what’s the first (i.e., left-most) screen, what’s the screen right of the first screen and so on. Do you get my idea?
I’m aware that this only makes sense if all of your screens have the same y-offset. It wouldn’t work for this guy, for example, because of those two monitors on top of the others.
Offline
What I don’t like about feh is that it relies “Xinerama order”: First “Xinerama screen” gets the first wallpaper and so on. Just like you do it in setroot. This is totally fine when you only have one screen but I have three screens and—sometimes—their order changes. (I don’t know why exactly.) It would be ultra-nice if setroot had a “--use-geometry” option. When using this option, setroot uses the screens’ position (`x_org` and `y_org` as returned by `XineramaQueryScreens()`) to figure out what’s the first (i.e., left-most) screen, what’s the screen right of the first screen and so on. Do you get my idea?
Yes I see what you are saying... If I added the ability to specify the Xinerama monitor for the wallpaper, would that work? The only issue that starts arising is if someone uses multiple X servers which all use Xinerama. That can be one hell of a nightmare, but a fun exercise.
Character shines in the great moments, but is polished in the little ones.
Offline
added global "--blank-color" option to branch develop. if you have multiple monitors but don't set images to all of them, this will set the bg color of the "blank walls".
note that if you only have one monitor and do not set any images, but call this option, you will still receive "no images supplied" message.
if no images are supplied, blank walls are still set to blank color, but you receive warning message. e.g.
setroot --blank-color blue
on n monitors will set all monitors to a solid color background of blue, with a warning message that no images were supplied.
Last edited by ttz (2014-11-11 16:01:18)
Character shines in the great moments, but is polished in the little ones.
Offline
Nice, I was thinking about doing the same for the exact same reasons.
What I don’t like about feh is that it relies “Xinerama order”: First “Xinerama screen” gets the first wallpaper and so on. Just like you do it in setroot. This is totally fine when you only have one screen but I have three screens and—sometimes—their order changes. (I don’t know why exactly.) It would be ultra-nice if setroot had a “--use-geometry” option. When using this option, setroot uses the screens’ position (`x_org` and `y_org` as returned by `XineramaQueryScreens()`) to figure out what’s the first (i.e., left-most) screen, what’s the screen right of the first screen and so on. Do you get my idea?
I’m aware that this only makes sense if all of your screens have the same y-offset. It wouldn’t work for this guy, for example, because of those two monitors on top of the others.
Hi Vain,
I have implemented an "--on" option so that you can specify which screen you want the wallpaper to be on, so that you don't have to fuss as much over the order. This is in the develop branch. Would this solve your problem? I am hesitant to implement the "--use-geometry" option because, as you said, it would not work universally for all configurations.
Character shines in the great moments, but is polished in the little ones.
Offline
added --use-[xy]--geometry option, which assigns xinerama monitors based on the xposition and yposition of your monitors.
E.g. if you have three monitors horizontally laid out, xin screen 0 would be leftmost monitor, xin screen 1 middle, xin screen 2 rightmost, if --use-x-geometry is used.
Character shines in the great moments, but is polished in the little ones.
Offline
Hi,
“--on n” would not have solved my particular issue because I don’t know which monitor is monitor 0. But “--use-x-geometry” works perfectly! Thank you!
Offline
added a --greyscale option (makes wallpaper black and white, looks nice if you use it with contrast/sharpen/blur). for those lazy among us who don't want to actually open gimp/imagemagick and do a conversion.
Last edited by ttz (2014-11-28 14:47:32)
Character shines in the great moments, but is polished in the little ones.
Offline
I have a weird problem using setroot(-git) on a virtualbox Arch
$ pacman -Q setroot-git
setroot-git v1.1.2.g7676062-1
I have tried the regular non-git version in AUR with the same problem
I can set my wallpaper, but I can't store it
[oliver@awesomo ~]$ setroot -s ~/downloads/synced/backgrounds/archwp.jpg
[oliver@awesomo ~]$ ls -l ~/.setroot-restore
ls: cannot access /home/oliver/.setroot-restore: No such file or directory
[oliver@awesomo ~]$ setroot --store
Warning: no images were supplied.
If I manually create the .setroot-restore file, it complains of not being able to find the image
[oliver@awesomo ~]$ echo "-s ~/downloads/synced/backgrounds/archwp.jpg" > ~/.setroot-restore
[oliver@awesomo ~]$ ls -l ~/.setroot-restore
-rw-r--r-- 1 oliver oliver 45 Dec 5 12:43 /home/oliver/.setroot-restore
[oliver@awesomo ~]$ setroot --restore
Image ~/downloads/synced/backgrounds/archwp.jpg
not found.
[oliver@awesomo ~]$ ls -l ~/downloads/synced/backgrounds/archwp.jpg
-rw-r--r-- 1 oliver oliver 535012 Aug 9 20:47 /home/oliver/downloads/synced/backgrounds/archwp.jpg
How would I continue troubleshooting from here?
edit - to confirm, the initial 'setroot -s /path/to/file' does indeed work every time
Here's what each command does for me:
setroot -s /whatever/file = works
setroot --store = does not create the ~/.setroot-restore file and reverts me back to no wallpaper
setroot --restore = complains the file in ~/.setroot-restore doesn't exist
another edit - I'm using the same app on a regular Arch (not virtualbox) installation and have no issues (same synced files for background images) so I suspect it's something vbox-y.
Last edited by oliver (2014-12-05 18:25:23)
Offline
I have a weird problem using setroot(-git) on a virtualbox Arch
$ pacman -Q setroot-git setroot-git v1.1.2.g7676062-1
I have tried the regular non-git version in AUR with the same problem
I can set my wallpaper, but I can't store it
[oliver@awesomo ~]$ setroot -s ~/downloads/synced/backgrounds/archwp.jpg [oliver@awesomo ~]$ ls -l ~/.setroot-restore ls: cannot access /home/oliver/.setroot-restore: No such file or directory [oliver@awesomo ~]$ setroot --store Warning: no images were supplied.
If I manually create the .setroot-restore file, it complains of not being able to find the image
[oliver@awesomo ~]$ echo "-s ~/downloads/synced/backgrounds/archwp.jpg" > ~/.setroot-restore [oliver@awesomo ~]$ ls -l ~/.setroot-restore -rw-r--r-- 1 oliver oliver 45 Dec 5 12:43 /home/oliver/.setroot-restore [oliver@awesomo ~]$ setroot --restore Image ~/downloads/synced/backgrounds/archwp.jpg not found. [oliver@awesomo ~]$ ls -l ~/downloads/synced/backgrounds/archwp.jpg -rw-r--r-- 1 oliver oliver 535012 Aug 9 20:47 /home/oliver/downloads/synced/backgrounds/archwp.jpg
How would I continue troubleshooting from here?
edit - to confirm, the initial 'setroot -s /path/to/file' does indeed work every time
Here's what each command does for me:
setroot -s /whatever/file = works
setroot --store = does not create the ~/.setroot-restore file and reverts me back to no wallpaper
setroot --restore = complains the file in ~/.setroot-restore doesn't existanother edit - I'm using the same app on a regular Arch (not virtualbox) installation and have no issues (same synced files for background images) so I suspect it's something vbox-y.
Initial troubleshoot: try "echo "/home/<username>/<image path>" > ~/.setroot-restore" in your vbox, and then try "setroot --restore".
I'm not a vbox user so I am unfamiliar with how env variables are set, but I suspect it has something to do with the "$HOME" variable not being expanded. Try opening a terminal in the vbox and executing "echo $HOME" and pasting the output.
Basically, when "setroot --store" is called, what is supposed to be written is the full path of the image, without the "~" alias... i.e. it should be "/home/ttzhou/....." rather than "~/...".
Let me know how that goes. Thanks for reporting
Tim
Character shines in the great moments, but is polished in the little ones.
Offline
First fully-qualified test:
[oliver@awesomo ~]$ echo /home/oliver/downloads/synced/backgrounds/archwp.jpg > .setroot-restore
[oliver@awesomo ~]$ date
Fri Dec 5 17:58:27 EST 2014
[oliver@awesomo ~]$ ls -l ~/.setroot-restore
-rw-r--r-- 1 oliver oliver 55 Dec 5 17:58 /home/oliver/.setroot-restore
Same error
[oliver@awesomo ~]$ setroot --restore
Image /home/oliver/downloads/synced/backgrounds/archwp.jpg
not found.
Both ~ and $HOME expand as expected in the shell (tmux in urxvt)
[oliver@awesomo ~]$ echo $HOME
/home/oliver
[oliver@awesomo ~]$ echo ~
/home/oliver
I did some more playing around and found the following:
this works
[oliver@awesomo ~]$ setroot -s /home/oliver/downloads/synced/backgrounds/archwp.jpg --use-x-geometry 1
this fails
[oliver@awesomo ~]$ setroot --store
Warning: no images were supplied.
But this works :-)
[oliver@awesomo ~]$ echo '-s /home/oliver/downloads/synced/backgrounds/archwp.jpg --use-x-geometry 1' > ~/.setroot-restore
[oliver@awesomo ~]$ setroot --restore
[oliver@awesomo ~]$
And this fails:
[oliver@awesomo ~]$ echo '-s ~/downloads/synced/backgrounds/archwp.jpg --use-x-geometry 1' > ~/.setroot-restore
[oliver@awesomo ~]$ setroot --restore
[oliver@awesomo ~]$ Image ~/downloads/synced/backgrounds/archwp.jpg not found.
So... on virtualbox only (windows 7 host if it makes a difference), I have to add the --use-x-geometry flag to the .setroot-restore file and you're right in saying that ~ doesn't expand
Either way, it wasn't a *huge* deal because I could always call the full command directly, just one of those things that bugged me :-)
I'm by no means a developer but it looks like running 'setroot --restore' doesn't have the same environment as a regular shell?
Last edited by oliver (2014-12-05 23:15:38)
Offline
This is pretty sweet: thank you.
One much appreciated feature would be the ability to point it at ${XDG_CONFIG_DIR:-$HOME/.config}...
Offline
I did some more playing around and found the following:
this works
[oliver@awesomo ~]$ setroot -s /home/oliver/downloads/synced/backgrounds/archwp.jpg --use-x-geometry 1
this fails
[oliver@awesomo ~]$ setroot --store Warning: no images were supplied.
This is intended behaviour; if you call "--store" without options, it will not store anything and you will receive the typical warning message you see there. Did you try "setroot --store -s /home/oliver/downloads/synced/backgrounds/archwp.jpg"? See if that works with "setroot --restore".
But this works :-)
[oliver@awesomo ~]$ echo '-s /home/oliver/downloads/synced/backgrounds/archwp.jpg --use-x-geometry 1' > ~/.setroot-restore [oliver@awesomo ~]$ setroot --restore [oliver@awesomo ~]$
And this fails:
[oliver@awesomo ~]$ echo '-s ~/downloads/synced/backgrounds/archwp.jpg --use-x-geometry 1' > ~/.setroot-restore [oliver@awesomo ~]$ setroot --restore [oliver@awesomo ~]$ Image ~/downloads/synced/backgrounds/archwp.jpg not found.
So... on virtualbox only (windows 7 host if it makes a difference), I have to add the --use-x-geometry flag to the .setroot-restore file and you're right in saying that ~ doesn't expand
It actually has nothing to do with the "--use-x-geometry" flag - what is happening is that in your line
echo '-s /home/oliver/downloads/synced/backgrounds/archwp.jpg --use-x-geometry 1' > ~/.setroot-restore
you are giving the full path (i.e. not aliasing "/home/oliver" as "~").
When "setroot --restore" is called, it basically looks in ~/.setroot-restore and passes its contents as a command line argument (char** argv, if you are familiar with standard C functions) to setroot, which then parses it as normal. When you instead use
echo '-s ~/downloads/synced/backgrounds/archwp.jpg --use-x-geometry 1' > ~/.setroot-restore
it is passing this literal string as a command line argument, preventing your shell from expanding the "~" to the proper "/home/oliver".
Either way, it wasn't a *huge* deal because I could always call the full command directly, just one of those things that bugged me :-)
I'm by no means a developer but it looks like running 'setroot --restore' doesn't have the same environment as a regular shell?
It is something I will think about. I don't know if C has a way of telling your shell to expand "~" before it gets passed.
Character shines in the great moments, but is polished in the little ones.
Offline
This is pretty sweet: thank you.
Not a problem, thank you for the feedback! I am glad someone found a use for it.
One much appreciated feature would be the ability to point it at ${XDG_CONFIG_DIR:-$HOME/.config}...
Good idea. When I get a chance (probably sometime this weekend) I will see if I can add a "--store-in-dir" option that lets you specify a specific directory. I am also going to change the default behaviour of "--store" to place the restore file in "${XDG_CONFIG_DIR:-$HOME/.config}/setroot"... conforms better to XDG specifications.
(a "--store-in-dir" option would overly complicate things when it comes to restoring)
Last edited by ttz (2014-12-06 04:45:01)
Character shines in the great moments, but is polished in the little ones.
Offline
I understand now about my mis-use of the '--store' flag (I thought it was reading what was currently set) but if you look in the first two code boxes of my previous post, I don't understand why that failed
Offline
I understand now about my mis-use of the '--store' flag (I thought it was reading what was currently set) but if you look in the first two code boxes of my previous post, I don't understand why that failed
If you call "setroot --store /home/oliver...." and then call "setroot --restore", I believe you should be fine.
The problem arose when you did "echo /home/oliver... > .setroot-restore". echo adds a trailing newline to the string it is passed (I think this is so you have nice spacing when you actually echo it in terminal). This newline character is interpreted as being part of the string, so effectively, your .setroot-restore line is "/home/oliver...\n". Calling "setroot --restore" then has setroot look for "/home/oliver...\n" which obviously does not exist unless your image name happens to have a "\n" character appended to its filename.
You can rectify this by doing "echo -n /home/oliver.... > .setroot-restore" (i.e. adding the -n flag to echo). See if that works
Character shines in the great moments, but is polished in the little ones.
Offline
One much appreciated feature would be the ability to point it at ${XDG_CONFIG_DIR:-$HOME/.config}...
Both the stable and git packages now place ".setroot-restore" in ${XDG_CONFIG_HOME:-$HOME/.config}.
Character shines in the great moments, but is polished in the little ones.
Offline
jasonwryan wrote:One much appreciated feature would be the ability to point it at ${XDG_CONFIG_DIR:-$HOME/.config}...
Both the stable and git packages now place ".setroot-restore" in ${XDG_CONFIG_HOME:-$HOME/.config}.
Nice: thank you
Offline
If you call "setroot --store /home/oliver...." and then call "setroot --restore", I believe you should be fine.
correct :-)
You can rectify this by doing "echo -n /home/oliver.... > .setroot-restore" (i.e. adding the -n flag to echo). See if that works
correct again :-)
Thanks for taking the time to explain it.
Offline
I updated the documentation and did some tag juggling because of a few rushed/poor commits... so if you get a message from pacman saying that the git version is a downgrade, please ignore and proceed as usual.
basically I didn't actually write anywhere in the documentation to create the directory ${XDG_CONFIG_HOME:-$HOME/.config}/setroot/. if you use AUR, this is done in PKGBUILD; otherwise, you'll have to mkdir the directory manually.
my bad on this one.
Character shines in the great moments, but is polished in the little ones.
Offline
it did not create the directory when updated the AUR
Offline
it did not create the directory when updated the AUR
I cannot reproduce; on a clean install, using the PKGBUILD for both stable and git, the directory
${XDG_CONFIG_HOME:-$HOME/.config}/setroot
is created.
Perhaps you meant ".setroot-restore" file was not created?
EDIT: Another possibility: retagging the repo caused the git version to "downgrade". Try uninstalling the package, downloading it straight from AUR, run makepkg and reinstall. See if that works. (Juggling versions caused the version to "regress" - git can be a headache if you are careless like I am).
Last edited by ttz (2014-12-11 14:54:49)
Character shines in the great moments, but is polished in the little ones.
Offline
Mhhh, that `mkdir` line does not look right:
package() {
cd $_pkgname
mkdir -p ${XDG_CONFIG_HOME:-$HOME/.config}/setroot
make PREFIX="usr" DESTDIR="$pkgdir" install
}
More specifically, a PKGBUILD should not touch data outside the build directory. (Unless there have been changes in the AUR philosophy that I’m unaware of.)
This particular line can’t work reliably, anyway. It only creates the directory for that user who creates the package. What if I create the package as user A and run `setroot` as user B?
IMO, the correct way to deal with this situation is for `setroot` to check whether the directory exists. If it doesn’t, `setroot` should create it on-the-fly. Of course, this should be mentioned in the documentation.
Offline