You are not logged in.
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.
Yes, you are right; it was a temporary fix and shoddy practice.
C's method of creating directories is new to me and having read it, seems a bit of a pain; I'll have to get back to this when I have a bit more time.
Thank you for your advice.
Character shines in the great moments, but is polished in the little ones.
Offline
Latest version of setroot-git and git repo now automatically creates ${XDG_CONFIG_HOME:-$HOME/.config}/setroot/.setroot-store" and parent directories if needed. If anyone can test this, thanks in advance.
Slight rant: I really, really hate C's standard string functions.
Character shines in the great moments, but is polished in the little ones.
Offline
It would be simpler, and more desirable, IMO, to use a directive in the install file:
"If you haven't created a config file for setroot, you will need to do so: ${XDG_CONFIG_HOME:-$HOME/.config}/setroot/.setroot-store"
You should probably add a FILES section to the man page as well...
Offline
It would be simpler, and more desirable, IMO, to use a directive in the install file:
"If you haven't created a config file for setroot, you will need to do so: ${XDG_CONFIG_HOME:-$HOME/.config}/setroot/.setroot-store"You should probably add a FILES section to the man page as well...
What is considered better etiquette in this case... automatically create the file and specify in documentation/man page, or do what you have suggested?
The FILES suggestion makes sense.
Character shines in the great moments, but is polished in the little ones.
Offline
My preference is to assume Archers are competent enough to be able to manage $HOME and to leave any changes in that dir to them.
Offline
My preference is to assume Archers are competent enough to be able to manage $HOME and to leave any changes in that dir to them.
Though this comment is very true, I decided to leave the autocreation in; in the future I may want to use that directory to store other files.
I have added the FILES section of the man, and will add an install file with a post_install message that tells them such a directory was installed. I also went back and made all the code that creates the path code-safer (strn{dup, cat, cpy} instead of str{dup, cat, cpy}); I'll push this sometime tomorrow, if anyone is still cloning
Thanks for the advice, I am learning more and more about good practice in both AUR and coding (I hope).
EDIT: It is pushed now. I think it works and all is well *fingers crossed*. I appreciate Perl a lot more after working with C string and file I/O.
Last edited by ttz (2014-12-12 14:39:14)
Character shines in the great moments, but is polished in the little ones.
Offline
just a small question... if .setroot-store is now in ~/.config/setroot, any reason why it remains a hidden file? Why not just call it setroot-store?
Offline
just a small question... if .setroot-store is now in ~/.config/setroot, any reason why it remains a hidden file? Why not just call it setroot-store?
Nostalgia? In all honesty, there's no good reason, unless there is some standard I am unaware of.
Also, to anyone who cloned/updated and had errors, the latest version stable and git has hopefully fixed these... learning C string handling as I go along.
Character shines in the great moments, but is polished in the little ones.
Offline
I have tried pretty much every wallpaper setter (xsetroot, hsetroot, feh, nitrogen) and have never been completely happy with any of them. I was using imlibsetroot until today and am very glad to finally find something I will be happy to stick with. Setroot doesn't have some of the things imlibsetroot has like centering at a specific position, choosing specific dimensions, and weird scaling, but I never used any of that anyway.
The "-z" and "--restore" features are extremely convenient! Setroot also works much better for me with monitors added with xrandr, and I don't get the weird errors I did before.
One thing I do find to be a potential shortcoming is that wallpapers get reset when using "--on", and the wallpapers for different monitors have to all be set at the same time (or you end up with black screens). With imlibsetroot, if you can somehow set different wallpaper for different monitors with multiple "-x" flags, I could never get it working, so I'm glad that it at least works in the first place with setroot. However, especially for people who use extra monitors with a laptop like me, this can be quite inconvenient. Sometimes I connect a monitor or tv to my laptop, but I don't always have one connected. I find it to be a nuisance to have to retype the wallpaper command originally used for the screen on my laptop in addition to one for an added monitor after connecting it (can't always copy/paste the original command if I didn't call setroot from the commandline).
I had a couple ideas for dealing with this to make things more convenient. I think the best possibility would be to be able to specify wallpaper and options for monitors that aren't connected and properly store them. For example, this would mean that one could specify and store a command with wallpaper/options for "--on" 0-2 even if only 0 existed. At least one of the numbers should exist, or I think it should still be an error. That or there could be some specific flag like "--ignore-unconnected" that doesn't affect "--store". The command would only bother setting the wallpaper for monitor 0, but the options and wallpaper for the other monitor numbers would be stored properly. Then, if monitors 1 and 2 were connected at a later time, one could run "setroot --restore" and the sections for these monitors would no longer be ignored.
This would mean that one could use a single command to set all their wallpaper instead of having to keep appending things to a command every time a monitor was added. While it's possible to just put a long wallpaper command in an alias or function used for adding a monitor, it's not very pretty, means that this long command must be duplicated in several places (e.g. ~/.xinitrc and ~/.bashrc) and changed in all of them every time someone wants to change their wallpaper, and will cause an error when used with "--store"/"--restore" since "--store" won't work with a command that sets different wallpaper on multiple monitors. So it is possible to somewhat work around the issue but at the loss of the benefits of "--restore" and with a few other inconveniences swapped in. I've described this idea and error upon a "--restore" in more detail in this github issue.
Anyway, thank you for the great program! Everything else about it seems perfect so far.
Last edited by angelic_sedition (2014-12-13 20:29:46)
Offline
Anyway, thank you for the great program! Everything else about it seems perfect so far.
Thank you for the kind words Your issues with other *setroots mirror my own and are what led to me writing it in the first place!
I have read both your post here and on github and have commented on the issue.
Last edited by ttz (2014-12-13 22:39:09)
Character shines in the great moments, but is polished in the little ones.
Offline
angelic_sedition wrote:Anyway, thank you for the great program! Everything else about it seems perfect so far.
Thank you for the kind words
Your issues with other *setroots mirror my own and are what led to me writing it in the first place!
I have read both your post here and on github and have commented on the issue.
I added a dev branch to the repo to address the issues you posted. Can you try cloning and testing (thanks in advance).
Character shines in the great moments, but is polished in the little ones.
Offline
Latest commit/package:
version 1.4
can now handle poorly named images (spaces, percent signs, etc.)
can now "preset" unconnected monitors (see docs/man, or ask here for examples)
(trying to make) libxinerama optional dependency using #ifdef and #ifndef
I am expecting some issues, so for those still using, thanks for your patience and let me know if anything catastrophic happens. The main thing I am worried about is the last bullet point... I don't feel like uninstalling libxinerama to test, but if anyone wants to try, I would be eternally grateful.
Character shines in the great moments, but is polished in the little ones.
Offline
Latest commit/package:
version 1.4
depends=('imlib2' 'libX11')
The typoed upper case X in libX11 causes a pkg not found error.
Offline
Thanks, fixed.
Character shines in the great moments, but is polished in the little ones.
Offline