Difference between revisions of "User:Xterminus/Perl Background Rotation/Extensions"
(remove language suffix from Category:Perl Background Rotation (English), see Talk:Table of Contents#English Category Names: Capitalization and Conflict with i18n)
|Line 1:||Line 1:|
[[Category:Perl Background Rotation
[[Category:Perl Background Rotation]]
Revision as of 16:19, 23 April 2012
These features are disabled by default. You will need to spend time carefully reading through your .wallrc file to ensure that these perform correctly.
- Introduction : What this does
- Installation : Getting the basics handled.
- Using Extensions : Optional feature setup.
- Script Extras : Related Software
- Tips and Tricks : Fun for the whole family!
- Hacking : How to create your own extensions
- Code : Code walkthrough and some design notes
- FAQ : Frequently Asked Questions
- Screenshot Gallery : If you use these scripts, show off!
- Resources : A comprehensive wallpaper list.
Image Mangling, cropping, etc
Setting this up should be pretty straightforward if you read through the configuration file. You should be aware however, that this particular feature above all others can push your cpu hard. You WILL want to run this script at nice priority 10 or above in order to limit the effect this script may have on your performance.
Here is an example showing two different auto-generated wallpaper themes which use the "image mangling" function.
Configuration File Tweaking
The wallie daemon has a pretty sophisticated color scheme generation function. You can use the colors generated by this function in order to create or update configuration files for pretty much any software in GNU/Linux that uses a textfile for its configuration data.
In general, the process works like this. Any user wishing to make use of this process should supply a "template" configuration file. The daemon will read in the template and spit out a completed configuration file. When the render process is complete, the daemon will attempt execute a system command in order to tell the target program to reload it's configuration. In conky, this is a SIGUSR1 signal, in Openbox, it's a SIGUSR2, and in gnome you change a gconf registry key.
The following keywords will be replaced by real six digit hexadecimal color values. (The same as web pages).
_NORM_BASE_ _NORM_DARK_ _NORM_PALE_ _NORM_LPALE_ _WARM_BASE_ _WARM_DARK_ _WARM_PALE_ _WARM_LPALE_ _WARMER_BASE_ _WARMER_DARK_ _WARMER_PALE_ _WARMER_LPALE_ _WARMEST_BASE_ _WARMEST_DARK_ _WARMEST_PALE_ _WARMEST_LPALE_ _COOL_BASE_ _COOL_DARK_ _COOL_PALE_ _COOL_LPALE_ _COOLER_BASE_ _COOLER_DARK_ _COOLER_PALE_ _COOLER_LPALE_ _COOLEST_BASE_ _COOLEST_DARK_ _COOLEST_PALE_ _COOLEST_LPALE_ _COMP_BASE_ _COMP_DARK_ _COMP_PALE_ _COMP_LPALE_ _COMP_WARM_BASE_ _COMP_WARM_DARK_ _COMP_WARM_PALE_ _COMP_WARM_LPALE_ _COMP_WARMER_BASE_ _COMP_WARMER_DARK_ _COMP_WARMER_PALE_ _COMP_WARMER_LPALE_ _COMP_COOL_BASE_ _COMP_COOL_DARK_ _COMP_COOL_PALE_ _COMP_COOL_LPALE_ _COMP_COOLER_BASE_ _COMP_COOLER_DARK_ _COMP_COOLER_PALE_ _COMP_COOLER_LPALE_
This simple chart shows the relationship between the various colors, using a base color of 8c7746 ( a tan/brown ).
Color selection can be tricky. My implementation works like this:
First, the brightness of the background's mean color is set to 50%. This ensures that we don't end up with a scheme that's garish or pale. Then the saturation is determined (the saturation is the difference between the values of red/green/blue). If the saturation level is determined to be too low, a "preset" is selected as the base color.
The color scheme are generated by picking for colors based on the "base" color, then shifting about 30 degrees in each direction on the color-wheel and repeating the process for "warm" and "cool" schemes. The daemon then shifts clockwise and counter-clockwise again to generate "warmer, cooler, warmest, and coolest" schemes. Finally, the complementary color schemes are picked by selecting the color 180 degrees out of phase with the base color, and then shifting clockwise and counterclockwise again.
Everyone has a favorite conky configuration. If you would like to modify your own to act as a template, it's not brain surgery. However, you might want to look at my conky template as a reference.
This perl script will read up template and transform it into a new one. Said in other words. Do not point conky to use the template file, point conky to the output conky file.
When the new file is written, a SIGUSR1 signal is sent to all running conky processes. This signal tells conky that it's configuration has changed and that it needs to reload. This is fairly painless process, although while conky is reloading it may "stick" or flicker.
Note: If you make other major changes to your conky config, those changes may not take with only a SIGUSR1 signal. I noticed that while colors change just fine on a SIGUSR1, other aspects of conky do not. For example: when adding brand new text or variables, conky does not seem to add them to the output text.
The process for creating a conky and openbox theme is virtually identical. The only difference seems to be that openbox seems to behave best when it's sent a SIGUSR2 signal.
GTK themes can now be templated. A sample GTK theme based on the Murrine GTK engine is provided in the tarball.
Setup for GTK theming is a little weird. Basically, Gnome and GTK apps will not reload theme information unless you actually change the theme value in the gconf registry to something else. So you should place the gtk theme in .themes/Wallie1 and then create a symbolic link from Wallie1 to Wallie2. As each theme is generated, the daemon will toggle between these two directories (Wallie1 and Wallie2), which will ensure your gnome apps stay current.
urxvt Blurry Terminals
Blurring the backgrounds of your transparent terminals can improve the readability of text. Take a look at these two (nearly) identical terminals.
In addition to improving the readability, it looks kinda neat. I stumbled across this this effect while playing with the automove-background urxvt perl extension.
Fou will need to copy urxvt-theme into either a private bin folder or /usr/lib/urxvt/perl, you will need probably want to modify your .Xdefaults file to make use of this extension too.
These settings seem to work well for me.
urxvt*inheritPixmap: false urxvt*fading: 20 urxvt*fadeColor: black urxvt*tintColor: #EFEFEF urxvt*foreground: #EFEFEF urxvt*background: black urxvt*internalBorder: 0 urxvt*perl-lib: /home/cpm/bin/perl urxvt*perl-ext-common: automove-background,urxvt-theme
the perl-lib is the path to your personal urxvt library. You can omit this if you copy urxvt-theme into /usr/lib/urxvt/perl.
Alternately, you can execute the urxvt extension with the following urxvt commandline:
urxvt -pe automove-background,urxvt-theme
Please note that this has not been throughly tested with urxvtc and urxvtd.
How it works
The urxvt extension basically opens a UNIX socket connection to the wallie process and waits for update information. When wallie generates a new background, it blasts out an UPDATE command to every urxvt terminal listening on the socket.
The process is VERY fast and lightweight, and the urxvt theme extension has gone through several large revisions in order to make it so.
The urxvt-theme extension is not a stand-alone urxvt extension. It requires a running copy of the wallpaper daemon so that urxvt terminals have somewhere to pull configuration information from.