Merge branch 'master' into kbdd-layout-update

Author: bergentroll

.gitignore

@@ -0,0 +1 @@
+*.swp

CONTRIBUTING.md

@@ -21,19 +21,21 @@ interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
 5. Any non-obvious assumptions required to make the configuration work SHOULD 
    be included either in the `README.md` or as comments in the configuration.
 6. A blocklet's suggested command SHOULD be of the form
-   `command=/path/to/myscript[.ext] [args...]` even
-   if the script is a single line.
-7. The command file (`myscript[.ext]` above) SHOULD be the entirety of the
+   `command=$SCRIPT_DIR/myscript [args...]` even
+   if the script is a single line. The [args...] SHOULD be empty, in favor of
+   using injected properties.
+7. The command file (`myscript` above) SHOULD be the entirety of the
    executable part of your blocklet, i.e. your code is a single script.
-8. The command file's name, up to extension, SHOULD match the name of the 
-   containing directory. E.g. `myscript/myscript.ext` and `myscript/myscript`
-   are both good names, but `myscript/yourscript.ext` is not.
+8. The command file's name, SHOULD match the name of the 
+   containing directory. E.g. `myscript/myscript`
+   is a good name, but `myscript/yourscript` is not.
 9. A blocklet SHOULD NOT have a separate non `i3blocks.conf` configuration
    file. Any extra configuration (e.g. default colors, paths, etc.) SHOULD be 
-   contained in the command file near the top.
-10. A blocklet SHOULD include at least one screenshot of what it looks like in
+   injected properties.
+10. A blocklet MUST include at least one screenshot of what it looks like in
    action.
-11. A blocklet SHOULD NOT require building.
+11. A blocklet MAY require building/compiling, but if it does the build process SHOULD be
+   as simple as possible (preferably nothing more than running `make`)
 12. A blocklet SHOULD include a `LICENSE` file.
 13. A blocklet MAY include a `.gitignore` file.
 
@@ -47,16 +49,20 @@ interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
 # Pull request guidelines
 
 1. Every commit being merged in a pull request MUST begin with the name of the 
-   blocklet it concerns.
+   blocklet it concerns, .e.g. `myscript: update colors`
 2. A contributor with write access MUST NOT merge any pull request that he or
-   she created.
+   she created, unless there are no other contributors with write access 
+   currently active.
 3. Commit messages SHOULD be written in imperative form. E.g. 
    `myscript: add option to configure colors`, instead of
    `myscript: added option to configure colors`.
 4. Commit message first lines SHOULD be 72 characters or less but descriptive, 
    and details MAY be added to subsequent lines.
-5. A pull request SHOULD contribute significant change to exactly one
-   blocklet. A bug fix will usually be considered a significant change.
+5. Commit details SHOULD write `Fixes: [issue]` or `Closes: [issue]` if
+   the commit is meant to fix/close an issue on the issues page.
+6. A pull request SHOULD contribute significant change to exactly one
+   blocklet. A bug fix or new injected property will usually be considered 
+   a significant change.
 
 # Example workflow
 
@@ -70,14 +76,14 @@ In case you have never made a pull request before, here is an example workflow.
 3. You fork the i3blocks-contrib repository on github, and clone your fork of
    i3blocks-contrib onto your computer with `git clone [your fork here]`.
 4. You copy your `myscript` directory to the top level of the cloned
-   i3blocks-contrib directory and change to the top level directory.
+   i3blocks-contrib directory and `cd` to the top level directory.
 5. You `git add myscript` to tell git to track your blocklet's directory, you 
    will need to do this before every commit.
 6. You `git commit` and leave a commit message of the form
    `myscript: add myscript, a short description of myscript`
 7. Perhaps you make a few last minute changes, and add another commit.
 8. You squash your commits into one with `git rebase -i` and follow the
-   instruction, leaving only your first commit and commits that were already 
+   instructions, leaving only your first commit and commits that were already 
    there unsquashed.
 9. You push your changes to your fork on github with `git push`.
 10. You navigate to vivien's i3blocks-contrib, click "pull requests" and
@@ -93,7 +99,8 @@ In case you have never made a pull request before, here is an example workflow.
 13. You push to your remote fork of i3blocks-contrib, and the changes 
    automatically get incorporated into the pull request process.
 14. A maintainer with write access to vivien's i3blocks-contrib decides your
-   script is ready to be merged and merges it in.
+   script is ready to be merged and merges it in, possibly making minor changes
+   of their own in the process.
 
 Whenever you make a significant change to your blocklet or fix a bug,
 squash your local commits since your last pull request and replace the commit

ISSUE_TEMPLATE.md

@@ -0,0 +1,15 @@
+### Expected behavior
+
+
+### Actual behavior
+
+
+### i3blocks config relevant to blocklet(s)
+
+
+### Output of blocklet(s) when run from command line
+
+
+### Output of any relevant other commands that might help diagnostics
+
+

README.adoc

@@ -0,0 +1,73 @@
+= Community contributed blocklets
+
+This repository contains a set of scripts (a.k.a. *blocklets*) for link:https://github.com/vivien/i3blocks[i3blocks], contributed by the community.
+
+|===
+| Blocklet | Description
+| link:afs[] | Show usage information for an AFS directory
+| link:apt-upgrades[] | Show system upgrades using aptitude
+| link:arch-update[] | Show AUR updates using yaourt
+| link:aur-update[] | Show AUR updates
+| link:bandwidth[] | Show bandwidth information (default bash version)
+| link:bandwidth2[] | Show bandwidth information (C version)
+| link:bandwidth3[] | Show bandwidth information (another bash version)
+| link:battery[] | Show battery info
+| link:battery2[] | Pretty battery info
+| link:batterybar[] | Show battery info graphically as a bar
+| link:calendar[] | Current date/time and click for calendar
+| link:cpu_usage[] | Show current CPU usage
+| link:cpu_usage2[] | Show current CPU usage (C version)
+| link:disk[] | Show disk usage (space used) for a given directory
+| link:disk-io[] | Monitor disk reads and writes
+| link:docker[] | Show the number of Docker containers and container IP
+| link:email[] | Show the number of unread IMAP messages
+| link:essid[] | Show the wifi ESSID you are connected to
+| link:gpu-load[] | Shows load of Nvidia GPUs
+| link:iface[] | Show network interface IP/status
+| link:kbdd_layout[] | Show the keyboard layout using dbus and kbdd
+| link:keyindicator[] | Show the status of capslock or numlock
+| link:key_layout[] | Show the current keyboard layout using setxkbmap
+| link:kubernetes[] | Show the kubernetes current context and namespace
+| link:load_average[] | Show the system 1 minute load average
+| link:mediaplayer[] | Generic media player status/controls using playerctl
+| link:memory[] | Show ram or swap usage
+| link:monitor_manager[] | Manage monitor on/off, resolution, extend, clone
+| link:nm-vpn[] | Show vpn status using network manager
+| link:openvpn[] | Show openvpn status
+| link:rofi-calendar[] | Current date/time and click for callendar using rofi
+| link:shutdown_menu[] | Shutdown menu using rofi or zenity
+| link:tahoe-lafs[] | Show status of your tahoe-lafs grid
+| link:temperature[] | Show system temperatures using lm-sensors
+| link:time[] | Show the current date/time and click to change timezones
+| link:usb[] | Show connected usb storage device info
+| link:volume[] | Show the current system volume (default)
+| link:volume-pulseaudio[] | Pretty print system volume for pulseaudio
+| link:wifi[] | Show the strength of your wifi connection in percent
+| link:wlan-dbm[] | Show wifi interface link quality in dBm or percent
+| link:ytdl-mpv[] | Play youtube videos from your clipboard using youtube-dl
+|===
+
+It is officially maintained by @kb100 with the help of a bench of active i3blocks crafters.
+
+Each release of this repository will be guaranteed to work against a given link:https://github.com/vivien/i3blocks/releases[release] of i3blocks (a.k.a. *core*).
+
+|===
+| contrib | core
+| master | master
+| next | next
+|===
+
+You may want to take a look at the individual blocklet directories, which contain descriptions, screenshots, and installation/configuration instructions.
+
+NOTE: configurations reference `$SCRIPT_DIR`, meaning the directory that you put the script into. +
+You must change `$SCRIPT_DIR` appropriately to coincide with where you put your scripts, for more info see the link:https://github.com/vivien/i3blocks-contrib/wiki/FAQ#blocklets-refer-to-script_dir-what-does-that-mean-how-can-i-use-it[FAQ].
+
+Want to contribute?
+Great!
+Check the link:https://github.com/vivien/i3blocks-contrib/blob/master/CONTRIBUTING.md[contribution guidelines] in order to get started.
+
+NOTE: i3blocks now supports dynamics properties, and all scripts have been updated to do the same. +
+i3blocks-contrib REQUIRES a version of i3blocks that supports dynamics properties, which is currently only +
+available in the git version since the last release (v1.4) was years ago.
+
+Happy crafting!