Archive

Archive for the ‘Misc’ Category

MarkdownPresenter: create slides from markdown in a quick and easy way

September 9, 2018 Leave a comment

MarkdownPresenter is a very simplistic markdown presentation editor and viewer that uses markdown to create pdf slides. Especially its simplicity makes it a good choice for quickly creating some slides – for which other tools would easily be too bloated. To use MarkdownPresenter you just need to:

MarkdownPresenter usage

MarkdownPresenter uses regular markdown, with one exception:

  • ---, ***, or ___ indicates the end of a slides/start of the next slide, instead of introducing a horizontal line.

Therefore, to make slides, you will use

  • #, ##, etc. to create headlines
  • *, 1., to create bullet points and enumerations` to create links
  • ![]() to include figures

Even tables work as expected:

# Tables
|A|B|C|
|---:|:---|---|
|test|Test|ab|
|1|2|3|

Below is the source for a small MarkdownPresenter demo presentation with the corresponding pdf being available here (a bigger example is available at https://jsakamoto.github.io/MarkdownPresenter/Presenter.html#1):


# Marp

Is a very simplistic markdown presentation editor and viewer. It can export markdown to pdf slides.

* Download from https://github.com/jsakamoto/MarkdownPresenter
* Start Marp by executing the `Marp` executable file.

---

# Marp Usage

Marp uses regular markdown, with one exception:

* `---`, `***`, or `___` indicates the end of a slides/start of the next slide, instead of introducing a horizontal line.

Therefore, to make slides, you will use:

* #`, `##`, etc. to create headlines
* *`, `1.`, to create bullet points and enumerations
* `[]()` to create links
* `![]()` to include figures
* ...

---

# Marp Usage

Even tables work as expected:

|A|B|C|
|---:|---:|:---|
|test|Test|ab|
|1|2|3|

 

git-difftool: an easy way to highlight changes in git-managed text files

In two previous posts (post one, post two) we have shown how to use git latexdiff and latexdiff to visually highlight the differences of a Latex file in between its different versions in the form of a Latex-compiled diff file. For comparing arbitrary textfiles instead of Latex files, no Latex-based visual comparison is available. However, git itself ships a nice little tool to compare two different versions of the same textfile and highlight its differences: git difftool. It basically does two things for you:

  • Checkout the versions of the file to compare
  • Fire up your diff program to show you/highlight the differences

All you need to do is specify the file and the versions you want to compare.

Configuration

git_icon

git difftool is part of the git installation. However, it needs to know which diff program you want to use when calling git difftool. You can specify this by adding the following snippet to your ~/.gitconfig:

[diff]
    tool = MY-DIFF-TOOL

where MY-DIFF-TOOL could be vimdiff, kdiff3, or similar (ensure the tool you specify is installed and available in the PATH on your machine). Now git difftool should be ready for usage:

user@machine:~$ git difftool -h
usage: git difftool [-t|--tool=] [--tool-help]
                    [-x|--extcmd=]
                    [-g|--gui] [--no-gui]
                    [--prompt] [-y|--no-prompt]
                    [-d|--dir-diff]
                    ['git diff' options]

Usage

git difftool has a simple call syntax (in fact the same as git diff). The command you might want to compare files might be similar to this:

git difftool COMMIT1 COMMIT2 FILE

If you use

--

as COMMIT1 and leave out COMMIT2 you will see the differences between the file in its current, possibly unstaged/uncommited stage and its last commit. If you specify a hash for COMMIT1 and use

--

as COMMIT2 you will see the differences of the current file to the specified commit instead. If you specify hashes for both COMMIT1 and COMMIT2 you will see the differences between those two versions of the file.

Reduce pdf file size with GhostScript pdf compression under Linux/Unix

March 19, 2018 Leave a comment

We frequently need to mail pdf files that are too big for regular mail services, such as a 40MB pdf file with a maximum 10MB send restriction. In such situations quick and effective pdf compression comes in handy that does not reduce the quality to a level of the file becoming unusable.

GhostScript

GhostScript LogoUnder Linux and Unix-like systems GhostScript is one of the most powerful tools (probably the most powerful one) to manipulate files like pdf, ps, etc. If you are on a Linux/Unix-like system and need a job with pdf files done check out the “How to use GhostScript” site. It’s not unlikely that GhostScript already has a built in solution to your problem. Consequently it also features a way of effectively compressing pdf files with different options and settings.

GhostScript pdf compression

Effective pdf compression is possible with GhostScript using a single command (adapted from here and here):

gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/screen -dNOPAUSE -dQUIET -sOutputFile=outputfile.pdf inputfile.pdf

-dPDFSETTINGS= specifies the quality level of the pdf file. This effects embedded pixel graphics (also adapts embedded color profiles) and is the main option for controlling the compression level, thereby the resulting file size:

  • -dPDFSETTINGS=/screen (72 dpi images)
  • -dPDFSETTINGS=/ebook (150 dpi images)
  • -dPDFSETTINGS=/printer (300 dpi images)
  • -dPDFSETTINGS=/prepress (300 dpi images, color preserving)
  • -dPDFSETTINGS=/default

Other switches: the output is written as pdf (-sDEVICE=pdfwrite), the pdf compatibility level is set to 1.4 (-dCompatibilityLevel=1.4), the process does not require user interaction (-dNOPAUSE and -dQUIET), and GhostScript skips the startup message (-dQUIET).

Categories: Linux, Misc Tags: , , , , , , , ,

Redshift: protect your eyes during long nights in front of your PC

January 20, 2018 Leave a comment

For the night owls amongst us: looking at our screens during long night sessions – thereby at the whole spectrum of visible light from blue to red – means accepting a bunch of unhealthy drawbacks. For example: as the blue part of the spectrum of visible light is usually only visible during daytime our bodies have adapted to using it as a “clock” mechanism: while we see blue light we i.e. release hormones that keep us awake. That can e.g. make falling asleep more difficult/can cause insomnia when we have worked in front of a monitor for a couple of hours until late in the night. Therefore, besides dimming monitors (reduces the contrast to the dark surroundings), reducing the amount of blue light during night sessions and causing a tinge of red on our monitors is a good thing – not only for our eyes, but also for our bodies as a whole.

How to cause a redshift on your screen

Luckily for the night owls amongst us this problem has been recognized and addressed for different platforms already: for example, even many mobile phones provide for the functionality to redshift screen colors nowadays. For Linux, applications that do this job for us include redshift, openlux, and f.lux (the latter seems to be the original thing but is closed source). My current personal recommendation would be to use redshift, as it’s open source, included in the repositories of all major distributions, easy configurable, and does the job with a single command on your terminal. One word for the curious: from the technical perspective redshift relies on an X server extension to function.

Redshift logo

Redshift project logo

In terms of features redshift automatically adjusts screen colors to better match what the natural light would be – which would be caused by a sun that has probably already set hours ago, meaning there should be no blue light at all. redshift uses your location and time to adjust the screen colors. It provides for deriving the location automatically, but I personally like providing it by hand (see example below). Next to the location the second important setting is what you want your screen colors to be during daytime and nighttime (the color temperature in K to be exact). Both settings can be provided as parameters when calling redshift from the terminal:

redshift -t DAYTEMPERATURE:NIGHTTEMPERATURE -l LAT:LON

For example, I use those color temperatures and coordinates (for the latter providing exact data is not as important as it might seem):

redshift -t 6500:3200 -l 48:14

One more hint: of course you can autostart redshift with i3 by adding this line to your ~/.i3/config/i3.config:

exec --no-startup-id redshift -t 6500:3200 -l 48:14

 

git-latexdiff errors? Workaround: using latexdiff manually allows fixing broken things

December 4, 2017 Leave a comment

In a previous post we have highlighted git-latexdiff, which visually highlights the changes between two versions of the same latex file managed with git – without you being required to checkout any versions of that file yourself. In certain cases git-latexdiff might terminate with errors instead of producing a visual diff file. For example, it might struggle with broken latex code, broken figures, certain usage of subfiles, etc. In such cases, it might help to manually do what git-latexdiff would do fully automatically for you. Here’s a simple step-by-step explanation of how you could achieve visual highlighting even with broken Latex files:

  • Have the repository R2 available, which contains the file F in the newer version you want compared. Copy the repository R2 to a different folder R1 (you could do this on other ways too, but with copying you can hardly mess things up). In the copied folder checkout the version of the repository which contains F in the older version you want compared. Therefore, R2 contains F in the new version and R1 contains F in the old version now.
  • You can now fix both versions of F  should they contain broken latex code. F essentially needs to compile in both R2 and R1.
  • If you run into troubles with figures (also in subsequent steps) it might be helpfull to add the “draft” parameter to the documentclass. This can be done in both F files or in the diff.tex generated later. It disables figures in the documents, which causes less problems later in case figures are part of what prevents latexdiff, pdflatex, or one of the other tex tools from doing their jobs. This might also the case if figures have both been added and removed, or if figure paths have changed between those versions.

After those preparations, in your terminal run the following command from somewhere outside both repositories:

latexdiff --append-safecmd=subfile R1/path/to/F R2/path/to/F --flatten > diff.tex

The option

--apend-safecmd=subfile

makes the subfile command safe to use within the scope of the “\DIFadd” or “\DIFdel” commands, which latexdiff uses to mark differences between versions. The option

--flatten

replaces “\input” and “\include” commands within body by the content of the files in their argument. This makes all content of the document appear in your highlighted diff in the end. If the latexdiff-command succesfully generated a diff.tex file, copy this file into R2 or R1, right next to where F is located. You should now be able to compile and show the pdf file:

pdflatex diff.tex && biber diff && pdflatex diff.tex && evince diff.pdf

Fixing even more problems

In case you run into errors during compilation using the method above you might be able to manipulate the diff.tex file. If this does not help and if you are just interested in differences in the plain text there is an even stronger workaround you can try: you can copy the important parts of the content of your main .tex files in both R1 and R2 into newly created – and therefore clean – dummy.tex files. The important part of the text will usually be textual paragraphs, and more importantly for big documents, includes of subfiles. The dummy.tex files need to be of the same document class (e.g. a book class document will need a clean book again to work).  Remember to do this in an identical way in both R1 and R2. Afterwards you can compare the dummy.tex files using latexdiff (instead of the original main files). Doing so can circumvent many different types of problems that might be introduced due to code in custom Latex .cls or .sty files that is either unsupported by latexdiff and/or is broken in some way.

git latexdiff usage: visually highlight changes in version controlled Latex files

October 2, 2017 2 comments

This is a follow-up post to latexdiff-git, which is outdated by now.

latexdiff is a powerful tool that uses two Latex files to generate a third Latex file in which differences between the first two files are visually highlighted. latexdiff is especially useful when comparing an old with a new version of the same Latex file. However, latexdiff does not account for any version control on its own. This means that if you want to visually highlight the differences between two versions of a version controlled Latex file, you are required to manually checkout the two different versions ahead of comparing them with latexdiff. In case you are using git as your version control system, this is where git-latexdiff comes into play. It accounts for checking out the different version of a Latex file as well as comparing them with latexdiff in a single command: you only need to specify which latex file and versions should be used for the comparison.

Preconditions

Ensure you have git, a latex distribution (e.g. texlive-full), and latexdiff installed and available in the path of your CLI.

git-latexdiff installation

Clone git-latexdiff:

git clone https://gitlab.com/git-latexdiff/git-latexdiff#

Follow instructions in the README. This will involve a:

sudo make install

in most cases on an Ubuntu system. If all went well “git latexdiff” should be available in your CLI (it should print the help message):

user@machine:~$ git latexdiff

fatal: Please, provide at least one revision to diff with.
Usage: git latexdiff [options] OLD [NEW]
 git latexdiff [options] OLD --
 git latexdiff [options] -- OLD
Call latexdiff on two Git revisions of a file.

OLD and NEW are Git revision identifiers. NEW defaults to HEAD.
If "--" is used for NEW, then diff against the working directory.

Options:
 --help this help message
 --help-examples show examples of usage
 --main <file> name of the main LaTeX, R Sweave,
 or Emacs Org mode file.
 The search for the only file containing 'documentclass'
 will be attempted, if not specified.
 For non-LaTeX files, a reasonable `prepare` command
 will be used unless explicitly provided
 --no-view don't display the resulting PDF file
 --latex run latex instead of pdflatex
 --bibtex, -b run bibtex as well as latex
 (pdflatex,bibtex,pdflatex,pdflatex)
 --biber run BibLaTex-Biber as well as latex
 (pdflatex,bibtex,pdflatex,pdflatex)
 --view view the resulting PDF file
 (default if -o is not used)
 --pdf-viewer <cmd> use <cmd> to view the PDF file (default: $PDFVIEWER)
 --no-cleanup don't cleanup temp dir after running
 --no-flatten don't call latexpand to flatten the document
 --cleanup MODE Cleanup temporary files according to MODE:

- keeppdf (default): keep only the
 generated PDF file

- none: keep all temporary files
 (may eat your diskspace)

- all: erase all generated files.
 Problematic with --view when the
 viewer is e.g. evince, and doesn't
 like when the file being viewed is
 deleted.

--latexmk use latexmk
 --latexopt pass additional options to latex (e.g. -shell-escape)
 -o <file>, --output <file>
 copy resulting PDF into <file> (usually ending with .pdf)
 Implies "--cleanup all"
 --tmpdirprefix where temporary directory will be created (default: /tmp).
 Relative path will use repository root as a base
 --verbose, -v give more verbose output
 --quiet redirect output from subprocesses to log files
 --prepare <cmd> run <cmd> before latexdiff (e.g. run make to generate
 included files)
 --ln-untracked symlink uncommited files from the working directory
 --version show git-latexdiff version.
 --subtree checkout the tree at and below the main file
 (enabled by default, disable with --whole-tree)
 --whole-tree checkout the whole tree (contrast with --subtree)
 --ignore-latex-errors keep on going even if latex gives errors, so long as
 a PDF file is produced
 --ignore-makefile ignore the Makefile, build as though it doesn't exist
 -* other options are passed directly to latexdiff
 --bbl shortcut to flatten a bbl file of the same name as the project
 --latexpand OPT pass option OPT to latexpand. Use multiple times like
 --latexpand OPT1 --latexpand OPT2 to pass multiple options.
 --latexdiff-flatten use --flatten from latexdiff instead of latexpand

Unrecognized options are passed unmodified to latexdiff.

git-latexdiff usage

The main CLI usage of git-latexdiff is:

git latexdiff --main YOURFILE OLD_HASH [NEW_HASH]

A bunch of useful options are available for git-latexdiff. For example:

-v # good in case you run into any errors
--cleanup keeppdf # delete the checked-out 'old' and 'new' folders but keep the pdf
--cleanup all # delete all generated files afterwards
--output FILE # copy pdf before deleting it to FILE (disables automatically viewing the pdf). good in combination with --cleanup all
--tmpdirprefix ./FOLDERNAME/ # alternative to the above: specify where temporary stuff is stored, makes it easier to access diff files. good in combination with --cleanup keeppdf
--bibtex # also run bibtex
--biber # also run biber

Therefore, the command you might want to run therefore might be similar to this:

git latexdiff --main MYFILE.tex --bibtex --output git-latexdiff.pdf --cleanup all OLD_HASH NEW_HASH

…where you can specify

--

as NEW_HASH, if you want to run git latexdiff against the current (possibly unstaged/uncommited) version of the file, or where you can leave out NEW_HASH completely, if you want to run it against the last commit. Or your command might look similar to this:

mkdir git-latexdiff; git latexdiff --main MYFILE.tex --tmpdirprefix ./git-latexdiff/ --cleanup keeppdf OLD_HASH

 

i3 window manager: quick setup and configuration

February 5, 2017 Leave a comment

i3_window_manager_screenshot

i3 example [Wikipedia]

The i3 window manager is a tiling window manager: it enables power users to operate/arrange/manage application windows in a very fast way in tiles, without any requirements to use a mouse. Alex Booker provides an excellent introduction and overview to the i3 window manager, which is divided into 3 videos: general introduction, configuration, and (visual) fine tuning. In this post we summarize the i3 configuration we use atm for a quick lookup (which is partially based on Alex Booker’s videos).

Installation


sudo apt-get install i3

Logout, then login to i3. The i3 configuration wizard starts automatically if there is no i3 configuration file yet (we recommend using Super as the mod key at this point, because Alt is used by a huge amount of applications for other tasks). You can always remove the i3 config file at ~/.config/i3/config and start the wizard again using i3-config-wizard.

Basic usage

We strongly recommend to go through all the shortcuts in the official i3 reference card (it just takes a moment and is the core of how you will operate i3 afterwards). Be aware that if you are using an alternative keyboard layout, i3 automatically detects which keys are located at the positions that i3 would normally use – so you will be able to use the same physical keys, even if you are using a completely different layout.

After being aware of the basic usage of i3, skimming through the official i3 user’s guide will make sense. This should highlight the possibilities with i3 (in both how to operate i3 and how to configure it), which will make later configuration tasks easier by far.

i3 config file

The main i3 config is located in ~/.config/i3/conf. This file is created by i3-config-wizard at first and can be modified as wished afterwards.

Be aware that changing any i3 config at least requires i3 to be reloaded (“restarted in place”) with Mod+Shift+R. Some configuration also require the underlying application that is started/controlled by i3 (e.g. compton) to be restarted. If i3 restarts those applications on each reload depends on its configuration (that’s the difference between exec and exec_always in the config file). If the underlying application was started with exec, restarting the application by hand or logging out/loging back in is required.

(Re)starting i3 from command line

To start i3 from a native tty command line:

DISPLAY=:0 # or :1 etc...
export DISPLAY
# killall i3 # required in case i3 is running
i3 -c .config/i3/config

To instead restart a running i3 from a native tty command line:

i3-msg reload
i3-msg restart

Media buttons etc.

Most likely i3 does not recognize your media buttons correctly from the beginning. You at first need playerctl to enable control over (parts) of the media buttons, of which you can get different packages (including .deb) here. The i3 FAQ then provides a config snippet that can be copied (appended) to your i3 config file to map keys to the media buttons. Be aware that the number of the pulse audio device may be different (in the script it’s 0, but for others it might e.g. be 1). If e.g. the buttons cause the currently focused window to flicker, but the volume does not change, this might be an indication for using the wrong device. If you want to specify the player that you control with the play/pause/next/previous buttons via playerctl buttons, you use the –player parameter, e.g. –player=rhythmbox. Be sure that the player provides an MPRIS D-Bus interface (e.g. vlc, audacious, spofity, etc). With Rhythmbox, for example, the corresponding plugin has to be enabled first.

Set wallpaper

You need e.g. feh to set a wallpaper in i3:


sudo apt-get install feh

By adding the following to your i3 config file you always set the wallpaper when i3 is started/reloaded:


exec_always feh --bg-scale /path/to/your/wallpaper.jpg

For different wallpaper scaling options, check out the man page of feh (it provides e.g. –bg-center, –bg-fill, –bg-max, –bg-scale, –bg-tile, …)

Launch applications on specified workspaces

At first, you need to find out the xprop window class of your target application. For this, start xprop and click on the application window. The 2nd string under WM_CLASS(STRING) is the string you need to know in the next step: add the following line to your i3 config file (and replace CLASS with the just determined string):


assign [class="CLASS"] 10

10 in this case indicates the nr. of the workspace the application window should be positioned.

Autostart applications

To automatically start applications, add one of the following lines to your i3 config file:


exec APPLICATION_COMMAND


exec_always APPLICATION_COMMAND

exec only executes the command when i3 is started, and exec_always executes the command each time i3 is reloaded. For example, starting your web browser is only useful for each fresh i3 start, but setting the wallpaper is useful to be done each time i3 is reloaded.

Monitor configuration

An easy way to configure the monitor setup using an UI is with arandr (UI for randr):


sudo apt-get install arandr

If you want to make a certain monitor configuration permanent you can a) configure monitors as wished in arandr, then b) save the configuration to a file, and c) add “exec_always CONFIG_FILE” to your i3 config file.

Wifi controls

i3 does not come with a built in UI for to control your wifi. To avoid configuring it via config files (which is still pretty cumbersome in Linux after all those years) you can use e.g. the graphical frontend wicd-gtk:


sudo apt-get install wicd-gtk
wicd-gtk

Change system fonts

One possible cosmetic improvement is to use different system fonts in i3. Alex recommends the Yosemite San Francisco Font: you can download it from its github page (under “manual install”), then change the font entry in the i3 config file to:


font pango:System San Francisco Display 10

Further, changing the font for the used gtk is recommended. You can do this is the gtk configuration file (in ~/gtkrc-2.0 and/or .config/gtk-3.0/…) by changing the font line to e.g.:


gtk-font-name="System San Franzisco 10"

Another option is to use the lxappearance config UI (but it currently seems buggy as not detecting all installed fonts correctly, as long they are not already in use with the system):


sudo apt-get install lxappearance
lxappearance

De-uglify i3

When you previously had Gnome Shell installed, you can use gnome-tweak-tool to configure your look-and-feel and add the following line to your i3 config file to “de-uglify” i3 at startup:

exec --no-startup-id gnome-settings-daemon

For further/other configuration or if the above approach does not work for you you can try lxappearance, gtk-chtheme, and qt4-config:

sudo apt-get install lxappearance gtk-chtheme qt4-qtconfig

Replace dmenu with rofi


sudo apt-get install rofi

In the i3 config file, replace the dmenu-shortcut with e.g.


bindsym $mod+a exec rofi -show run -lines 20 -eh 1.3 -opacity "85" -bw 0 -font "System San Francisco Display 10"

or, to have different colors:


set $bg-color   #2f343f
set $text-color #f3f4f5
bindsym $mod+a exec rofi -show run -lines 20 -eh 1.3 -opacity "90" -bw 0 -bc "$bg-color" -bg "$bg-color" -fg "$text-color" -hlbg "$text-color" -hlfg "$bg-color" -font "System San Francisco Display 10"

Transparency and fading effects

i3 does not provide for transparency or fading effects itself (it has less purpose in doing so, as e.g. windows don’t overlap in a tiling arrangement). To add those, use e.g. compton:


sudo apt-get install compton

and add “exec compton” to your i3 config file. The configuration is for compton is done via ~/.config/compton.conf, which you first have to copy from the example file location. With Ubuntu, this is:


cp /usr/share/doc/compton/examples/compton.sample.conf ~/.config/compton.conf

Afterwards, you can change settings there to your needs. We usually do the following:

  • Increase window fading speed, which is specified in milliseconds between fading steps: “”fade-delta = 5;”
  • Remove transparency from unfocused windows and menues (increases their readability). To do so, comment out “inactive-opacity” and “menu-opacity”.

Replace the i3status bar (bottom/top bar) with i3blocks


sudo apt-get install i3blocks

Copy the example i3blocks config file:


cp /etc/i3blocks.conf ~/.config/i3/i3blocks.conf

And change the value of the “status_command” from “i3status” with “i3blocks -c ~/.config/i3/i3blocks.conf” in your i3 config file.

Then you can customize i3blocks in your ~/.config/i3/i3blocks.conf file. For example:

  • Set the interval of date/time to 1 to have a 1s time update interval.
  • For volume add “command=/usr/share/i3blocks/volume 5 pulse” and set the interval 1 to use the pulse audio volume level with 1s interval.
  • Replace the text of labels with character/utf-8 icons as you like – this saves space in the bar. Alex has some nice examples for this in his own config file on github.

Update notification in i3blocks

The following script checks and prints if updates are available and if a reboot is required after updates:

#!/bin/bash                                                                                                        

# count how many updates we have got
ups=`/usr/lib/update-notifier/apt-check --human-readable | head -1 | awk '{print $1;}'`

# print the results
if [ "$ups" -eq "1" ]
then
  echo "There is 1 update"
elif [ "$ups" -gt "1" ]
then
  echo "There are $ups updates"
elif [ -f /var/run/reboot-required ]; then
     echo 'Reboot required'
else
  echo "Up to date"
fi

This script can be included in i3blocks by adding the following to in the i3blocks config file:

# Update status
[updates]
label=
interval=3600
command=/path/to/update/status/script/from/above

Workspaces on predefined screens

For users using a multi-monitor setup configuring to which screen specific workspace automatically go might be interesting:


# put workspaces on specific screens
workspace 1 output HDMI-1
workspace 2 output DVI-I-1
...

More i3 shortcuts

  • Auto back-and-forth: after switching from workspace A to workspace B, pressing the shortcut for workspace B again to switch back to workspace A. Add “workspace_auto_back_and_forth yes” to enable this feature.

Application configuration

Usability of some applications benefits from some more configuration:

  • The new mail attention add-on for Thunderbird makes i3 raise the urgent notification flag for new mails, so that the corresponding workspace is highlighted.
  • Enabling the “Message Notification” add-on in Pidgin makes i3 raise the urgent notification flag for new messages, so that the corresponding workspace is highlighted.

More hints

As i3 does not come with a built in network configuration UI: to configure networks like VPNs you can use the following (parts of the network-manager and network-manager-gnome packages):

  • nm-connection-editor allows editing network settings
  • nmtui allows for activating/deactivating networks over the command line

i3 does also not come with a built in UI for configuring computer mice. The mouse pointer speed can be adapted with xinput:

  • use “xinput –list –short” to determine the name of your mouse device, then
  • “xinput –set-prop “MOUSE DEVICE NAME” “Device Accel Constant Deceleration” 1.8″ to change the mouse pointer speed. The latter can be added to the i3 config file to automatically keep the speed after a restart of i3.

Backup your i3 configuration

Most (if not all) i3 configuration is located in those 3 files, which consequently are the only ones that need to be backed up:


~/.config/i3/config
~/.config/i3/i3blocks.conf
~/.config/compton.conf

Categories: Linux, Misc