Update README

This commit is contained in:
Utkarsh Verma 2021-10-12 20:37:59 +05:30
parent 65d12cf3c9
commit 47e7097dbc
No known key found for this signature in database
GPG Key ID: 817656CF818EFCCC

View File

@ -1,4 +1,4 @@
# dwmblocks # dwmblocks-async
A modular statusbar for `dwm` written in C. You may think of it as `i3blocks`, but for `dwm`. A modular statusbar for `dwm` written in C. You may think of it as `i3blocks`, but for `dwm`.
## Features ## Features
@ -12,7 +12,7 @@ A modular statusbar for `dwm` written in C. You may think of it as `i3blocks`, b
> Apart from these features, this build of `dwmblocks` is more optimized and fixes the scroll issue due to which the statusbar flickers on scrolling. > Apart from these features, this build of `dwmblocks` is more optimized and fixes the scroll issue due to which the statusbar flickers on scrolling.
# Why `dwmblocks`? ## Why `dwmblocks`?
In `dwm`, you have to set the statusbar through an infinite loop like this: In `dwm`, you have to set the statusbar through an infinite loop like this:
```sh ```sh
@ -41,24 +41,31 @@ What `dwmblocks` does is that it allows you to break up the statusbar into multi
What's even better is that you can externally trigger updation of any specific block. What's even better is that you can externally trigger updation of any specific block.
# Installation ## Why `dwmblocks-async`?
Everything I have mentioned till now is offered by the vanilla `dwmblocks`, which is fine for most users. What sets `dwmblocks-async` apart from vanilla `dwmblocks` is the 'async' part. `dwmblocks` executes the commands of each blocks sequentially which means that the mail and date blocks, from above example, would be executed one after the other. This means that the date block won't update unless the mail block is done executing, or vice versa. This is bad for scenarios where one of the blocks takes seconds to execute, and is clearly visible when you first start `dwmblocks`.
This is where the `dwmblocks-async` steps in tells the computer to execute each block asynchronously or simultaneously.
## Installation
The installation is simple, just clone this repository, modify `config.h` appropriately, and then do a `sudo make install`. The installation is simple, just clone this repository, modify `config.h` appropriately, and then do a `sudo make install`.
```sh ```sh
git clone https://github.com/UtkarshVerma/dwmblocks.git git clone https://github.com/UtkarshVerma/dwmblocks-async.git
vi config.h vi config.h
sudo make install sudo make install
``` ```
# Usage ## Usage
To have `dwmblocks` set your statusbar, you need to run it as a background process on startup. One way is by adding the following to `~/.xinitrc`. To have `dwmblocks-async` set your statusbar, you need to run it as a background process on startup. One way is by adding the following to `~/.xinitrc`.
```sh ```sh
# `dwmblocks-async` has its binary named `dwmblocks`
dwmblocks & dwmblocks &
``` ```
## Modifying the blocks ### Modifying the blocks
You can define your statusbar blocks in `config.h`. Each block has the following properties: You can define your statusbar blocks in `config.h`. Each block has the following properties:
Property|Value Property|Value
@ -71,20 +78,20 @@ The syntax for defining a block is:
```c ```c
static Block blocks[] = { static Block blocks[] = {
... ...
{"date", 1800, 1}, BLOCK("date", 1800, 1)
... ...
} }
``` ```
Apart from that you can also modify the block delimiters and width of each block as shown. Apart from that you can also modify the block delimiters and width of each block as shown.
```c ```c
// Maximum length of each block, expressed in number of characters. // Maximum possible length of output from block, expressed in number of characters.
#define CMDLENGTH 50 #define CMDLENGTH 50
#define DELIMITER " " #define DELIMITER " "
``` ```
## Signalling changes ### Signalling changes
Most statusbars constantly rerun every script every several seconds to update. This is an option here, but a superior choice is giving your module a signal that you can signal to it to update on a relevant event, rather than having it rerun idly. Most statusbars constantly rerun every script every several seconds to update. This is an option here, but a superior choice is giving your module a signal that you can signal to it to update on a relevant event, rather than having it rerun idly.
For example, the volume module has the update signal 5 by default. Thus, running `pkill -RTMIN+5 dwmblocks` will update it. For example, the volume module has the update signal 5 by default. Thus, running `pkill -RTMIN+5 dwmblocks` will update it.
@ -95,10 +102,10 @@ My volume module *never* updates on its own, instead I have this command run alo
Note that all modules must have different signal numbers. Note that all modules must have different signal numbers.
## Clickable modules ### Clickable modules
Like `i3blocks`, this build allows you to build in additional actions into your scripts in response to click events. You can check out [my statusbar scripts](https://github.com/UtkarshVerma/dotfiles/tree/gentoo/.local/bin/statusbar) as references for using the `$BLOCK_BUTTON` variable. Like `i3blocks`, this build allows you to build in additional actions into your scripts in response to click events. You can check out [my statusbar scripts](https://github.com/UtkarshVerma/dotfiles/tree/main/.local/bin/statusbar) as references for using the `$BLOCK_BUTTON` variable.
For this feature to work, you need `dwm` to be patched with [statuscmd](https://dwm.suckless.org/patches/statuscmd/). For this feature to work, you need `dwm` to be patched with [statuscmd](https://dwm.suckless.org/patches/statuscmd/).
# Credits ## Credits
This work would not have been possible without [Luke's build of dwmblocks](https://github.com/LukeSmithxyz/dwmblocks) and [Daniel Bylinka's statuscmd patch](https://dwm.suckless.org/patches/statuscmd/). This work would not have been possible without [Luke's build of dwmblocks](https://github.com/LukeSmithxyz/dwmblocks) and [Daniel Bylinka's statuscmd patch](https://dwm.suckless.org/patches/statuscmd/).