Getting older, not necessarily wiser!
In this post I will be reviewing the OpenBox Window Manager (WM). Over the past few months I have spent a significant amount of time installing, working with, configuring, and theming the OpenBox WM. I feel that because of this experience, I am now in a position to review the ins and outs of this particular WM.
This is going to be the first in a series of posts on different Window Managers. It will not be as detailed as some of my previous posts on Joe’s Window manager (JWM). While I will be discussing both configuration and theme, I am not going to present in depth information in either category. My goal here is to present a somewhat comprehensive review and provide a good staring point for anyone thinking about giving this window manager a try.
It is important to to distinguish between Window Managers and Desktop Environments. Most users are more familiar with the desktop environment. A desktop includes a windows management as one of many graphical tools and capabilities. Others include task bars, menu systems, docks, configuration systems, file managers, and desktop icons.
In contrast a window manager is generally much simpler and lighter, with the primary requirement being the management of windows. For example, LWM (Lightweight Window Manager) is a simple floating WM. All it does is allow you to manage windows. It has no other functionality. There are no configuration files (configuration is done at compile time).
JWM and OpenBox, are floating WM’s that offer additional features making them more user friendly. One of the main differences between WM’s is the feature set they come with.
Another concept to be familiar with is tiling vs floating (stacking) WM’s. Floating WM’s have windows that can be moved around and stacked on top of each other. Tiling WM windows can be moved around, but they can not be stacked. All windows are visible on the screen. The more windows you have open the smaller they can become. The workflow between the two is quite different, and many people tend prefer one type over the other.
This is a good jump off point as I have discussed JWM in detail under both Debian and Arch Linux distributions. Looking at the feature sets, both JWM and OpenBox are very similar. They both use floating windows and both have a menu system. But lets look at where they differ.
JWM has a task bar, and OpenBox does not. JWM can be configured and themed with a single file. OpenBox requires four or five files. Openbox is generally much more configurable than JWM, but is also correspondingly more complex to configure.
JWM is under active development. OpenBox is considered feature complete, and any work is restricted to error corrections and bug fixes.
Basically Openbox consists of several systems; floating Window manager, menu, key bindings, auto start, environment, themes, multiple work spaces, detailed configuration, and dock (OpenBox dock is a place to store running dock type application, I have never found it particularity useful though). Additionally there are several helper applications available. Note that system is a relative term in this case. We will be looking at some of these systems in a little more detail.
Configuration Options: Lets discuss this first. OpenBox can be configured globally (for all users) or locally for a specific user. Local configurations take priority over global configurations. We will start with global configuration.
The global configuration files are fond in two places; /etc/xdg/openbox and /usr/share/themes. In /etc/xdg/openbox we find;
OpenBox themes are stored in /usr/share/themes. A theme consists of a folder bearing the theme name, and an openbox3 directory within. This directory contains the themerc file, and possibly several window decoration icon files.
Local configuration files are the same as global. They are stored in the users home directory at ~/.config/openbox and ~/.themes
Window Management: As mentioned previously, OpenBox includes fairly standard floating or stacking window management. Windows include a title bar, handles for size adjustment, ability to be moved, and icons for things like shading, full screen, and closing. Almost every appearance aspect of a window can be modified through the theme system.
OpenBox is basically agnostic as far as widget tool kits are concerned. Widgets are the various components used in application to allow user interaction. The two major tool kits are GTK and QT. Application will load tool kit dependencies, however OpenBox itself is not dependent on a specific tool kit.
The look and feel of windows is set by either the global or local rc.xml and themrc files
Menus: The OpenBox menu system can be accessed by right clicking an empty spot on the desktop. Its contents are determined by either the local or global menu.xml file. How the menu looks is determiner by either the global or local themerc file.
Menus are static by default, but dynamic options are available.
Key Bindings: Key Bindings allow specific actions upon a specif combination of key presses. They are set in the global or local rc.xml file.
Most people are familiar with cut copy paste using control+x control+c and control+v. However many more combinations are possible. Some people love key binding, some never ruse them.
Some common key bindings you might think about setting; open and close a file manager, or terminal program, and setting up shortcuts for logging out or shutting down.
Auto start: You can auto start programs form the global or local autostart file. Some examples might be application like nitrogen (to set background wallpaper) or tint2 (launch a panel). Generally when using the autostart file you want to make sure programs run in the background.
Environment: As one might guess the global or local environment file is used to set various environmental functions. What I have used it for is to create variables pointing to various folders in /usr/share/icons. This way I don’t need to use the entire path when defining icons in the menu structure.
Multiple Virtual desktops: This can be set in the global or local rc.xml file. This basically gives you multiple work spaces to switch between.
In this section I will cover a few additional applications I have used during my testing to improve the overall experience of using OpenBox. I should note that if one adds a large number of helper applications, one will want to look at performance hits and possibly think about the benefits and disadvantages of using an actual desktop instead.
Menumaker: This is a python application (has python dependencies) for searching your installation, and adding application to your menu. It works with a number of WM’s including OpenBox. While this saves you from adding applications to the menu.xml file by hand, it finds lots of stuff you may or may not want in your menu system. Also, you may not like how it structures your menus. However it is a whole lot easier to remove or move items rather than adding them.
To run, you enter mmaker Openbox3. It should normaly write the menu.xml file to ~/.config/openbox. Use mmaker –help for additional information.
Obconf: This is the OpenBox graphical configuration editor. It allows you to change themes and adjust how the WM behaves.
Nitrogen: This application is used to set wallpaper though its graphical interface. From preferences you need to add a wallpaper directory, then select that wallpaper in the interface.
You can then add nitrogen –restore & to the OpenBox autostart file. Whenever you start OpenBox, nitrogen will restore the last wallpaper used. Note I replaced feh (which is command line and not as feature rich) with this application.
Tint2: This is a simple panel application, with a nice range of configuration options. If you need or desire a panel, it works well with Openbox.
You will want to run tint2 from the autostart file (tint2 &).
Picom: This is a light compositor for X-Windows. It is a fork of Compton. It can add things like transparency to OpenBox.
It can be run form the autostart file (picom &).
Conky: This is a light system monitor application. It can be rather complex to configure, so it is not for everyone.
It can be run from autostart (conky &).
I have found OpenBox light and fast. One of the main reasons I tried it out was that in Arch, JWM was moved form the main repository to an AUR (Arch user Repository). While it does not sport a panel, its window system and menu system are far more configurable. While it took a little getting used to, I am now fairy confident in using OpenBox as a light weight desktop.
Whenever I have used a desktop, I find myself using less than thirty percent of the built in functionality. OpenBox with a few helper applications can run much faster with less resources and meet ninety plus percent of my user needs.