Difference between revisions of "Monsterwm"

From ArchWiki
Jump to: navigation, search
m (Configuration: rm duplicate line)
(Compile from source)
(25 intermediate revisions by 7 users not shown)
Line 1: Line 1:
[[Category:Dynamic WMs (English)]]
+
[[Category:Dynamic WMs]]
{{i18n|Monsterwm}}
+
[https://github.com/c00kiemon5ter/monsterwm Monsterwm] is a minimal, lightweight, ''tiny but monstrous'' dynamic tiling window manager. It will try to stay as small as possible. Currently under 700 lines with the config file included. It provides a set of four different layout modes (vertical stack, bottom stack, grid and monocle/fullscreen) by default, and has floating mode support. Each virtual desktop has its own properties, unaffected by other desktops' settings. Finally monsterwm supports multiple monitors setups.
  
[https://github.com/c00kiemon5ter/monsterwm Monsterwm] is a minimal, lightweight, ''tiny but monsterous'' dynamic tiling window manager. It will try to stay as small as possible. Currently under 750 lines with the config file included. It provides a set of four different layout modes (vertical stack, bottom stack, grid and monocle/fullscreen), and has floating mode support. Each virtual desktop has its own properties, unaffected by other desktops' settings.
+
Monsterwm is written with '''{{ic|Xlib}}''' but there is also an '''{{ic|XCB}}''' fork available.
 
+
Monsterwm is writen with '''{{ic|Xlib}}''' but there is also an '''{{ic|XCB}}''' fork available. You can find it in the [[#Resources|Resources]]
+
  
 
== Installation ==
 
== Installation ==
=== Method 1 ===
+
Use one of the two methods described below.
Using AUR
+
  
Download the [https://aur.archlinux.org/packages.php?ID=55090 PKGBUILD from AUR]. Then, as a non-root user, run:
+
=== Using AUR ===
 +
Download the {{AUR|monsterwm-git}} or {{AUR|monsterwm-xcb-git}} package from the [[AUR]]. Then, as a non-root user, run:
  
 
  $ makepkg -i
 
  $ makepkg -i
  
while in the directory of the saved PKGBUILD. All the files will be retrieved, the package will be built and installed.
+
while in the directory of the saved [[PKGBUILD]]. All the files will be retrieved, the package will be built and installed.
  
=== Method 2 ===
+
=== Compile from source ===
Using git (recommended by monsterwm's author).
+
{{Note|This method is recommended by monsterwm's author.}}
  
Clone the [https://github.com/c00kiemon5ter/monsterwm official github repository] from github.
+
Clone the [https://github.com/c00kiemon5ter/monsterwm official github repository] from github:
  
 
  $ git clone git://github.com/c00kiemon5ter/monsterwm.git
 
  $ git clone git://github.com/c00kiemon5ter/monsterwm.git
 
  $ cd monsterwm
 
  $ cd monsterwm
 +
 +
Or clone the [https://github.com/Cloudef/monsterwm-xcb xcb-based fork]:
 +
{{Warning|As of Jan 6th, 2013, the xcb fork of monsterwm is heavily outdated and should not be used at this moment. C00kie has plans for porting monsterwm to xcb himself though.}}
 +
 +
$ git clone git://github.com/Cloudef/monsterwm-xcb.git
 +
$ cd monsterwm-xcb
  
 
To build monsterwm, run the following as a non-root user:
 
To build monsterwm, run the following as a non-root user:
Line 32: Line 36:
 
  # make clean install
 
  # make clean install
  
Before you build monsterwm, you may want to skip to the [[#Configuration|Configuration]] section and [[#Customization|Customization]] to change the default configuration.
+
Before you build monsterwm, you may want to jump to the [[#Configuration|Configuration]] section and [[#Customization|Customization]] to change the default configuration.
  
 
== Configuration ==
 
== Configuration ==
Monsterwm uses it's config.h file for configuration. By default, some hotkeys are already set.
+
Monsterwm uses its {{ic|config.h}} file for configuration. By default, some hotkeys are already set. {{Keypress|MOD1}} is the {{Keypress|Alt}} and {{Keypress|MOD4}} is the {{Keypress|Windows/Super}} key.  
  
'''Note''': the default MOD1 key is the Alt key.
+
* {{Keypress|MOD1 + h}} (decrease the size of a current window)
 +
* {{Keypress|MOD1 + l}} (increase the size of a current window)
 +
* {{Keypress|MOD1 + Shift + c}} (close current window)
 +
* {{Keypress|MOD1 + Tab}} (move to last desktop)
 +
* {{Keypress|MOD1 + k}} (change to previous window)
 +
* {{Keypress|MOD1 + j}} (change to next window)
 +
* {{Keypress|MOD1 + Shift + k}} (move current window up)
 +
* {{Keypress|MOD1 + Shift + j}} (move current window down)
 +
* {{Keypress|MOD1 + Enter}} (change master to current window)
 +
* {{Keypress|MOD1 + t}} (switch to tile mode)
 +
* {{Keypress|MOD1 + b}} (switch to bottomstack mode)
 +
* {{Keypress|MOD1 + g}} (switch to grid mode)
 +
* {{Keypress|MOD1 + m}} (switch to monocle mode)
 +
* {{Keypress|MOD4 + v}} (open dmenu - requires dmenu)
 +
* {{Keypress|MOD1 + Shift + Enter}} (open xterm)
 +
* {{Keypress|MOD1 + Left}} (previous desktop)
 +
* {{Keypress|MOD1 + Right}} (next desktop)
 +
* {{Keypress|MOD1 + F1-4}} (change to desktop #)
 +
* {{Keypress|MOD1 + Ctrl + q}} (quit monsterwm with exit value 1)
 +
* {{Keypress|MOD1 + Ctrl + r}} (quit monsterwm with exit value 0)
  
<ul>
 
<li>MOD + h (decrease the size of a current window)</li>
 
<li>MOD + l (increase the size of a current window)</li>
 
<li>MOD + Shift + c (close current window)</li>
 
<li>MOD + Tab (move to last desktop)</li>
 
<li>MOD + k (change to previous window)</li>
 
<li>MOD + j (change to next window)</li>
 
<li>MOD + Shift + k (move current window up)</li>
 
<li>MOD + Shift + j (move current window down)</li>
 
<li>MOD + Enter (change master to current window)</li>
 
<li>MOD + t (switch to tile mode)</li>
 
<li>MOD + b (switch to bottomstack mode)</li>
 
<li>MOD + g (switch to grid mode)</li>
 
<li>MOD + m (switch to monocle mode)</li>
 
<li>MOD4 + v (open dmenu - requires dmenu)</li>
 
<li>MOD + Shift + Return (open xterm)</li>
 
<li>MOD + Left (previous desktop)</li>
 
<li>MOD + Right (next desktop)</li>
 
<li>MOD + F1-4 (change to desktop #)</li>
 
<li>MOD + Control + q (quit monsterwm with exit value 1)</li>
 
<li>MOD + Control + r (quit monsterwm with exit value 0)</li>
 
</ul>
 
  
you can find more information in the man page
+
You can find more information in the man page ({{ic|man monsterwm}}).
 
+
$ man monsterwm
+
  
 
==Floating Mode==
 
==Floating Mode==
  
In floating mode one can freely move and resize windows in the screen space.  
+
In floating mode one can freely move and resize windows in the screen space. Changing desktops, adding or removing floating windows, does not affect the floating status of the windows. Windows will revert to their tiling mode position once the user selects a tiling mode. To enter the floating mode, either change the layout to {{ic|FLOAT}}, or enabled it by moving or resizing a window with the mouse, the window is then marked as being in floating mode.
Changing desktops, adding or removing floating windows, does not affect the floating status of the windows.  
+
Windows will revert to their tiling mode position once the user re-selects the current tiling mode.  
+
Note, that one cannot "select" the floating mode,  
+
but it will be enabled for any window if one tries to move or resize that window with the mouse.
+
The window is then marked, as being in floating mode.
+
  
 
==Panel==
 
==Panel==
Line 85: Line 79:
 
the current desktop and urgent hints whenever needed.  
 
the current desktop and urgent hints whenever needed.  
 
The user can use whatever tool or panel suits him best  
 
The user can use whatever tool or panel suits him best  
({{ic|dzen2}}, {{ic|conky}}, {{ic|[https://github.com/moetunes/Some_sorta_bar some-sorta-bar]}}, w/e),  
+
({{ic|dzen2}}, {{ic|conky}}, {{ic|[https://github.com/moetunes/Some_sorta_bar some-sorta-bar]}}, {{ic|[https://github.com/lemonboy/bar bar]}}, {{ic|[https://github.com/moetunes/bipolarbar bipolarbar]}}, {{ic|[https://github.com/c00kiemon5ter/mopag mopag]}}, w/e),  
 
to process and display that information.
 
to process and display that information.
 +
 +
To disable the panel completely set PANEL_HEIGHT to zero 0. The SHOW_PANELL setting controls whether the panel is visible on startup, it does not control whether there is a panel or not.
  
 
You can find an example of how to achieve this [https://gist.github.com/1905427 here].  
 
You can find an example of how to achieve this [https://gist.github.com/1905427 here].  
 
You can actually parse that information with any language you want,  
 
You can actually parse that information with any language you want,  
 
build anything you want,  
 
build anything you want,  
and display the information as you'd like.  
+
and display the information however you'd like.  
Do not be limited to that example.
+
Do not be limited by that example.
  
 
==Patches==
 
==Patches==
  
There are several patches that extend monsterwm's functionality.
+
Some extensions to the code are supported in the form of patches. See other branches for the patch and code. Easiest way to apply a patch, is to {{ic|git merge}} that branch.
  
* fib - adds fibonacci layout
+
Currently:
* monocleborders - adds borders to the monocle layout
+
* showhide - adds a function to show and hide all windows on all desktops
+
* uselessgaps - adds gaps around every window on screen
+
* warpcursor - cursors follows and is placed in the center of the current window
+
  
* bloat : bloat is merge of all patches with the current master, just for fun
+
* '''centerwindow''' : center new floating windows on the screen and center any window with a shortcut
* core  : core is is a very minimal subset of monsterwm, it's essentially its core, fully usuable at 610 loc
+
* '''fibonacci''' : adds fibonacci layout mode
 +
* '''initlayouts''' : define initial layouts for every desktop
 +
* '''monocleborders''' : adds borders to the monocle layout
 +
* '''nmaster''' : adds nmaster layout - multiple master windows for BSTACK and TILE layouts
 +
* '''rectangle''' : draws only a rectangle when moving/resizing windows to keep resources low (ie through an ssh forwarded session)
 +
* '''showhide''' : adds a function to show and hide all windows on all desktops
 +
* '''uselessgaps''' : adds gaps around every window on screen
 +
* '''warpcursor''' : cursors follows and is placed in the center of the current window
 +
* '''windowtitles''' : along with the rest desktop info, output the title of the current window
  
To install monsterwm with a patch simply change the {{bc|1=_gitbranch=}} line on the PKGBUILD to the name of the patch.
+
Another branch called [core], is an even more stripped and minimal version of monsterwm, on top of which the master branch is built and extended.
 +
 
 +
There is also xinerama support for multiple monitors.
 +
 
 +
* '''xinerama-core''' : the equivalent of core branch with xinerama support
 +
* '''xinerama-master''' : the equivalent of master branch with xinerama support
 +
* '''xinerama-init''' : configurable initial values for each desktop on each monitor
 +
 
 +
To install monsterwm with a patch, simply change the {{ic|1=_gitbranch=}} line in the PKGBUILD to the name of the patch.
  
 
----
 
----
  
If you installed monsterwm with [[#Method_2|method 2 - using git]], you can change to the desired branch with
+
If you installed monsterwm with the [[#Compile from source]] method, you can change to the desired branch with:
  
 
  $ git checkout <branch>
 
  $ git checkout <branch>
  
and then continue normally. For example to build monsterwm with the fibonacci layout one would do:
+
and then continue normally. For example to build monsterwm with the ''fibonacci'' layout one would do:
  
  $ git checkout fib
+
  $ git checkout fibonacci
 
  $ make
 
  $ make
 
  # make clean install
 
  # make clean install
  
That way you can also combine patches. To do that one would {{ic|merge}} another branch to the current one. For example to build monsterwm with uselessgaps, warpcursor and showhide, one would do:
+
That way you can also combine patches.  
 +
To do that one would {{ic|merge}} another branch to the current one.  
 +
For example to build monsterwm with ''uselessgaps'', ''warpcursor'' and ''showhide'', one would do:
  
 +
$ git config user.email <mailaddress>
 +
$ git config user.name <name>
 
  $ git checkout uselessgaps
 
  $ git checkout uselessgaps
  $ git merge showhide
+
  $ git checkout warpcursor
  $ git merge warpcursor
+
$ git checkout showhide
 +
$ git checkout master
 +
  $ git merge -m merge uselessgaps warpcursor showhide
 
  $ make
 
  $ make
 
  # make install
 
  # make install
Line 136: Line 150:
 
A rule is composed of four parts.
 
A rule is composed of four parts.
  
  { "MPlayer",    3,    True,  False },
+
/* class      desktop  follow  float */
 +
  { "MPlayer",    2,    True,  False },
  
 
* the class or instance name of the application
 
* the class or instance name of the application
* the desktop in which the application should appear - index starts from zero/0
+
* the desktop in which the application should appear - index starts from {{keypress|0}}
 
* whether that desktop should be focused when the application is started
 
* whether that desktop should be focused when the application is started
 
* whether the application should start in floating mode
 
* whether the application should start in floating mode
  
So the above rule, would place [[mplayer|this]] to desktop {{keypress|3}} and chage from the current desktop to that desktop, because {{ic|follow}} is {{ic|True}}. mplayer will be tiled as every other window.
+
So the above rule, would place [[MPlayer]] to desktop {{keypress|3}} and change from the current desktop to that desktop, because {{ic|follow}} is {{ic|True}}. MPlayer will be tiled as every other window.
  
 
To get the application class or instance name you can use {{ic|xprop | grep "WM_CLASS"}}.
 
To get the application class or instance name you can use {{ic|xprop | grep "WM_CLASS"}}.
Line 150: Line 165:
 
If we change the above rule to this one:
 
If we change the above rule to this one:
  
  { "MPlayer",    -1,   True,  True },
+
/* class      desktop  follow  float */
 +
  { "MPlayer",    -1,   True,  True },
  
then mplayer will be spawn in the current desktop, floating.
+
then MPlayer will be spawned in the current desktop, floating.
  
=== Add Custom Keybinds ===
+
=== Add custom keybinds ===
To add custom keybindings, you must edit config.h and recompile monsterwm.  
+
To add custom keybindings, you must edit {{ic|config.h}} and recompile monsterwm.  
 
That's why it is important to set them up on the initial installation to avoid having to do this again.
 
That's why it is important to set them up on the initial installation to avoid having to do this again.
I'll show you a scenario in which you would need to add a keybinding to open the thunar filemanager with {{keypress|MOD+t}}.
+
Below is a scenario in which you would need to add a keybinding to open the [[thunar]] filemanager with {{keypress|MOD1+t}}.
  
First, you must add a line such as the following underneath the already-defined {{ic|const char*}}'s
+
First, you must add a line such as the following, underneath the already-defined {{ic|const char*}}:
(Note: You can name it whatever you want. In this case, I named it {{ic|thunarcmd}}):
+
{{hc|config.h|<nowiki>
 +
/**
 +
* custom commands
 +
* must always end with ', NULL };'
 +
*/
 +
static const char *termcmd[] = { "xterm",    NULL };
 +
const char* thunarcmd[] = {"thunar", NULL};
 +
...</nowiki>
 +
}}
 +
{{Note| You can name it whatever you want. In this case, it is named {{ic|thunarcmd}}.}}
  
const char* thunarcmd[] = {"thunar", NULL&#125;&#125;;
+
{{ic|thunarcmd}} is just a title for the command you want to construct and run. Inside the curly brackets is where you define the command to be executed. Each command fragment that is separated by a space has its own value. For example the command sequence {{ic|ncmpcpp next}}, would be entered as {{ic|1={"ncmpcpp", "next", NULL}}}.
 +
The {{ic|NULL}} value '''must''' be included at the end of each hotkey.
  
{{ic|thunarcmd}} is just a title for the command you want to construct and run.
+
To actually register the hotkey with the window manager, you must look below that at the struct named {{ic|keys[]}}.  
Inside the curly brackets {{ic|{}} and {{ic|}}} is where you define the command to be executed.  
+
This is where monsterwm stores all of its keybindings.  
Each command fragment that is seperated by a space is it's own value.  
+
An example entry for the {{ic|thunarcmd}} made above would be:
What I mean by that is that the command sequence {{ic|ncmpcpp next}}
+
would be entered as {{ic|{"ncmpcpp", "next", NULL&#125;&#125;}.
+
The ''{{ic|NULL}}'' value ''must'' be included at the end of each hotkey.
+
  
To actually register the hotkey with the window manager, you must look below that at the struct named ''{{ic|keys[]''.  
+
{ MOD1,    XK_t,    spawn,     {.com = thunarcmd}},
This is where monsterwm stores all of it's keybindings.
+
An example entry for the {{ic|thunarcmd}} we made above would be:
+
  
{ MOD,    XK_t,    spawn,    {.com &#61; thunarcmd&#125;&#125;,
+
* The first element specifies the first keypress which is either:
 
+
** {{keypress|MOD1}} for the modkey only,  
* The first element specifies the first sequence that is pressed
+
** {{keypress|MOD1|SHIFT}} for the modkey and then the shift key,
** {{keypress|MOD}} for the modkey only,  
+
** {{keypress|MOD1|CONTROL}} for the modkey and then the control key,
** {{keypress|MOD&#124;SHIFT}} for the modkey and then the shift key,
+
** {{keypress|MOD&#124;CONTROL}} for the modkey and then the control key,
+
 
** {{keypress|0}} for no key at all.  
 
** {{keypress|0}} for no key at all.  
You can also use {{keypress|WINKEY}} which is the {{keypress|super}} or ''windows'' key instead of MOD.  
+
You can also use {{keypress|MOD4}} which is the {{keypress|super}} or {{keypress|windows}} key instead of {{keypress|MOD1}}.
 +
 
 +
* The second element specifies the actual key that is pressed to differentiate it from other similar hotkeys.
 +
In this case, we set it to {{keypress|t}}, which has {{ic|XK_}} in front of it because that is how [[Xorg]] reads key presses. Just remember to include {{ic|XK_}} in front of it. Some examples of these include {{keypress|XK_a}} for the {{keypress|a}} key, {{keypress|XK_Space}} for the {{ic|space bar}} and {{keypress|XK_1}} for the {{Keypress|1}} key.  
  
* The second element specifies the actual key that is pressed to differenciate it from other similar hotkeys.
+
Note that these are case-sensitive, so {{keypress|XK_a}} is not the same as {{keypress|XK_A}}. So for this example, the entire hotkey sequence that needs to be pressed is {{keypress|MOD1+t}}.
In this case, we set it to {{keypress|t}},
+
which has {{ic|XK_}} in front of it because that's how Xorg reads key presses.
+
Just remember to include {{ic|XK_}} in front of it and you'll be fine.
+
Some examples of these include {{keypress|XK_a}} for the {{keypress|a key}},
+
{{keypress|XK_Space}} for the {{ic|space bar}},
+
and {{keypress|XK_1}} for the {{Keypress|1 key}}.
+
Note that these are case-sensitive, so {{keypress|XK_a}} is not the same as {{keypress|XK_A}}.
+
So for this example, the entire hotkey senquence that needs to be pressed is {{keypress|MOD+t}}.
+
  
 
* The third element just specifies the function {{ic|spawn}}, which has been written to be passed a command to execute.  
 
* The third element just specifies the function {{ic|spawn}}, which has been written to be passed a command to execute.  
Line 198: Line 212:
  
 
* The final element inside the brackets specifies which command that was previously defined will be run.
 
* The final element inside the brackets specifies which command that was previously defined will be run.
In our case, it is {{ic|thunarcmd[]}},  
+
In our case, it is {{ic|thunarcmd[]}}, so we would do {{ic|<nowiki>{.com = thunarcmd}</nowiki>}}. The {{ic|.com}} stands for command.
so we would do {{ic|{.com &#61; thunarcmd&#125;}}.  
+
The {{ic|.com}} stands for command.
+
  
You can do the same with the {{ic|buttons[]}} struct.  
+
You can do the same with the {{ic|buttons[]}} structure.  
The buttons struct, uses the ''mouse'' instead of the keyboard.  
+
The buttons structure, uses the mouse instead of the keyboard.  
  
 
* Button1 is the left button
 
* Button1 is the left button
Line 215: Line 227:
 
==See also==
 
==See also==
 
* [https://bbs.archlinux.org/viewtopic.php?id=132122 monsterwm thread on the forums]
 
* [https://bbs.archlinux.org/viewtopic.php?id=132122 monsterwm thread on the forums]
 +
* [https://bbs.archlinux.org/viewtopic.php?id=141853 monsterwm screenshot thread]
 
* [https://github.com/c00kiemon5ter/monsterwm monsterwm repository on github]
 
* [https://github.com/c00kiemon5ter/monsterwm monsterwm repository on github]
 
* [https://github.com/Cloudef/monsterwm-xcb monsterwm-xcb repository on github]
 
* [https://github.com/Cloudef/monsterwm-xcb monsterwm-xcb repository on github]
 +
* [https://wiki.archlinux.org/index.php/Comparison_of_Tiling_Window_Managers Comparison of tiling window managers]

Revision as of 07:05, 6 January 2013

Monsterwm is a minimal, lightweight, tiny but monstrous dynamic tiling window manager. It will try to stay as small as possible. Currently under 700 lines with the config file included. It provides a set of four different layout modes (vertical stack, bottom stack, grid and monocle/fullscreen) by default, and has floating mode support. Each virtual desktop has its own properties, unaffected by other desktops' settings. Finally monsterwm supports multiple monitors setups.

Monsterwm is written with Xlib but there is also an XCB fork available.

Installation

Use one of the two methods described below.

Using AUR

Download the monsterwm-gitAUR or monsterwm-xcb-gitAUR package from the AUR. Then, as a non-root user, run:

$ makepkg -i

while in the directory of the saved PKGBUILD. All the files will be retrieved, the package will be built and installed.

Compile from source

Note: This method is recommended by monsterwm's author.

Clone the official github repository from github:

$ git clone git://github.com/c00kiemon5ter/monsterwm.git
$ cd monsterwm

Or clone the xcb-based fork:

Warning: As of Jan 6th, 2013, the xcb fork of monsterwm is heavily outdated and should not be used at this moment. C00kie has plans for porting monsterwm to xcb himself though.
$ git clone git://github.com/Cloudef/monsterwm-xcb.git
$ cd monsterwm-xcb

To build monsterwm, run the following as a non-root user:

$ make

To install monsterwm, run the following as root:

# make clean install

Before you build monsterwm, you may want to jump to the Configuration section and Customization to change the default configuration.

Configuration

Monsterwm uses its config.h file for configuration. By default, some hotkeys are already set. Template:Keypress is the Template:Keypress and Template:Keypress is the Template:Keypress key.


You can find more information in the man page (man monsterwm).

Floating Mode

In floating mode one can freely move and resize windows in the screen space. Changing desktops, adding or removing floating windows, does not affect the floating status of the windows. Windows will revert to their tiling mode position once the user selects a tiling mode. To enter the floating mode, either change the layout to FLOAT, or enabled it by moving or resizing a window with the mouse, the window is then marked as being in floating mode.

Panel

The user can define an empty space on the bottom or top of the screen, to be used by a panel. The panel is toggleable, but will be visible if no windows are on the screen. Monsterwm does not provide a panel and/or statusbar itself. Instead it adheres to the UNIX philosophy and outputs information about the existing desktops suchs as the number of windows and the tiling mode/layout of each desktop, the current desktop and urgent hints whenever needed. The user can use whatever tool or panel suits him best (dzen2, conky, some-sorta-bar, bar, bipolarbar, mopag, w/e), to process and display that information.

To disable the panel completely set PANEL_HEIGHT to zero 0. The SHOW_PANELL setting controls whether the panel is visible on startup, it does not control whether there is a panel or not.

You can find an example of how to achieve this here. You can actually parse that information with any language you want, build anything you want, and display the information however you'd like. Do not be limited by that example.

Patches

Some extensions to the code are supported in the form of patches. See other branches for the patch and code. Easiest way to apply a patch, is to git merge that branch.

Currently:

  • centerwindow : center new floating windows on the screen and center any window with a shortcut
  • fibonacci : adds fibonacci layout mode
  • initlayouts : define initial layouts for every desktop
  • monocleborders : adds borders to the monocle layout
  • nmaster : adds nmaster layout - multiple master windows for BSTACK and TILE layouts
  • rectangle : draws only a rectangle when moving/resizing windows to keep resources low (ie through an ssh forwarded session)
  • showhide : adds a function to show and hide all windows on all desktops
  • uselessgaps : adds gaps around every window on screen
  • warpcursor : cursors follows and is placed in the center of the current window
  • windowtitles : along with the rest desktop info, output the title of the current window

Another branch called [core], is an even more stripped and minimal version of monsterwm, on top of which the master branch is built and extended.

There is also xinerama support for multiple monitors.

  • xinerama-core : the equivalent of core branch with xinerama support
  • xinerama-master : the equivalent of master branch with xinerama support
  • xinerama-init : configurable initial values for each desktop on each monitor

To install monsterwm with a patch, simply change the _gitbranch= line in the PKGBUILD to the name of the patch.


If you installed monsterwm with the #Compile from source method, you can change to the desired branch with:

$ git checkout <branch>

and then continue normally. For example to build monsterwm with the fibonacci layout one would do:

$ git checkout fibonacci
$ make
# make clean install

That way you can also combine patches. To do that one would merge another branch to the current one. For example to build monsterwm with uselessgaps, warpcursor and showhide, one would do:

$ git config user.email <mailaddress>
$ git config user.name <name>
$ git checkout uselessgaps
$ git checkout warpcursor
$ git checkout showhide
$ git checkout master
$ git merge -m merge uselessgaps warpcursor showhide
$ make
# make install

Customization

Application Rules

One can define rules for a specific application, which will be applied once the application spawns. A rule is composed of four parts.

/* class      desktop  follow  float */
{ "MPlayer",     2,    True,   False },
  • the class or instance name of the application
  • the desktop in which the application should appear - index starts from Template:Keypress
  • whether that desktop should be focused when the application is started
  • whether the application should start in floating mode

So the above rule, would place MPlayer to desktop Template:Keypress and change from the current desktop to that desktop, because follow is True. MPlayer will be tiled as every other window.

To get the application class or instance name you can use xprop . If the desktop is set to a 'negative' number then the window spawns in the current desktop.

If we change the above rule to this one:

/* class      desktop  follow  float */
{ "MPlayer",     -1,   True,   True },

then MPlayer will be spawned in the current desktop, floating.

Add custom keybinds

To add custom keybindings, you must edit config.h and recompile monsterwm. That's why it is important to set them up on the initial installation to avoid having to do this again. Below is a scenario in which you would need to add a keybinding to open the thunar filemanager with Template:Keypress.

First, you must add a line such as the following, underneath the already-defined const char*:

config.h
/**
 * custom commands
 * must always end with ', NULL };'
 */
static const char *termcmd[] = { "xterm",     NULL };
const char* thunarcmd[] = {"thunar", NULL};
...
Note: You can name it whatever you want. In this case, it is named thunarcmd.

thunarcmd is just a title for the command you want to construct and run. Inside the curly brackets is where you define the command to be executed. Each command fragment that is separated by a space has its own value. For example the command sequence ncmpcpp next, would be entered as {"ncmpcpp", "next", NULL}. The NULL value must be included at the end of each hotkey.

To actually register the hotkey with the window manager, you must look below that at the struct named keys[]. This is where monsterwm stores all of its keybindings. An example entry for the thunarcmd made above would be:

{ MOD1,     XK_t,     spawn,     {.com = thunarcmd}},

You can also use Template:Keypress which is the Template:Keypress or Template:Keypress key instead of Template:Keypress.

  • The second element specifies the actual key that is pressed to differentiate it from other similar hotkeys.

In this case, we set it to Template:Keypress, which has XK_ in front of it because that is how Xorg reads key presses. Just remember to include XK_ in front of it. Some examples of these include Template:Keypress for the Template:Keypress key, Template:Keypress for the space bar and Template:Keypress for the Template:Keypress key.

Note that these are case-sensitive, so Template:Keypress is not the same as Template:Keypress. So for this example, the entire hotkey sequence that needs to be pressed is Template:Keypress.

  • The third element just specifies the function spawn, which has been written to be passed a command to execute.

Whenever you need to start an application or do anything that is not related to the internals of monsterwm spawn will be used.

  • The final element inside the brackets specifies which command that was previously defined will be run.

In our case, it is thunarcmd[], so we would do {.com = thunarcmd}. The .com stands for command.

You can do the same with the buttons[] structure. The buttons structure, uses the mouse instead of the keyboard.

  • Button1 is the left button
  • Button2 is the middle click
  • Button3 is the right button

After this, recompile, hope for no errors, and install.

See also