Openbox X5 Software
Diante Scharsch
Openbox is a lightweight, powerful, and highly configurable stacking window manager with extensive standards support. It may be built upon and run independently as the basis of a unique desktop environment, or within other integrated desktop environments such as KDE and Xfce, as an alternative to the window managers they provide. The LXDE desktop environment is itself built around Openbox.
Four key files form the basis of the openbox configuration, each serving a unique role. They are: rc.xml, menu.xml, autostart, and environment. Although these files are discussed in more detail below, to start configuring Openbox, it will first be necessary to create a local Openbox profile (i.e for your specific user account) based on them. This can be done by copying them from the global /etc/xdg/openbox profile (applicable to any and all users) as a template:
A good selection of themes are available in the openbox-themesAUR package or the AUR. Some GTK themes come with an Openbox theme as well. Both Openbox-specific and Openbox-compatible themes will be installed to the /usr/share/themes directory and will also be immediately available for selection.
Openbox will not always automatically reflect any changes made to its configuration files within a session. As a consequence, it will be necessary to manually reload those files after they have been edited. To do so, enter the following command:
Modifier keys play an important role in keybindings (e.g. holding down the Shift or Ctrl key in combination with another key to undertake an action). Using modifiers helps to prevent conflicting keybinds, whereby two or more actions are linked to the same key or combination of keys. The syntax to use a modifier with another key is:
Where available, it is possible to set the appropriate multimedia keys to perform their intended functions, such as to control the volume and/or the screen brightness. These will usually be integrated into the function keys, and are identified by their appropriate symbols. See Keyboard input for details.
Fast and efficient, while this type of menu can be used to select applications, it can also be useful to access specific functions and/or perform specific tasks (e.g. desktop configuration), leaving the access of applications to another process (e.g. the synapse or xfce4-appfinder applications).
menumaker automatically generates xml menus for several window managers, including Openbox, Fluxbox, IceWM and Xfce. It will search for all installed executable programs and consequently create a menu file for them. It is also possible to configure MenuMaker to exclude certain application types (e.g. relating to GNOME or KDE), if desired.
archlinux-xdg-menu will automatically generate a menu based on xdg files contained within the /etc/xdg/ directory for numerous Window Managers, including Openbox. Review the Xdg-menu#OpenBox article for further information.
This type of menu is akin to those provided by the taskbars of desktop environments such as Xfce or LXDE. Automatically updating on-the-fly, this type of menu can be powerful and very convenient. It may also be possible to add custom categories and menu entries; read the documentation for your intended dynamic menu to determine if and how this can be done.
obmenu-generatorAUR is highly recommended despite being an unofficial package. With the ability to be used as a static or dynamic menu, it is highly configurable, powerful, and versatile. Menu categories and individual entries may also be easily hidden, customised, and/or added with ease. The official homepage provides further information and screenshots.
xdotool is a package that can issue commands to simulate key presses / keybinds, meaning that it is possible to use it to invoke keybind-related actions without having to actually press their assigned keys. As this includes the ability to invoke an assigned keybind for the Openbox desktop menu, it is therefore possible to use XDoTool to turn the Openbox desktop menu into a panel menu. Especially where the desktop menu is heavily customised and feature-rich, this may prove very useful to:
Executing it will bring up the Openbox desktop menu. Consequently, where using a panel that supports drag-and-drop functionality to add new launchers, simply drag the executable script onto it before changing the icon to suit personal taste.
Although compositing is not a necessary component, it may specifically avoid issues such as screen distortion with oblogout, and visual glitches with terminal window transparency. See Xorg#List of composite managers for common choices.
Given the lack of a desktop environment with a plain Openbox install, it can be useful to install one or more application launchers as supplements to the Openbox menu system and the hotkeys. Lists of such launchers can be found at Category:Application launchers and List of applications/Other#Application launchers; popular examples are Gmrun and dmenu.
The openbox package provides a obxprop binary that can parse relevant values for applications settings in rc.xml. Officially obxprop grep "^_OB_APP" is recommended for this task. Start the process by running the command shown, then click a window to see its properties in the terminal.
To use Xorg-XProp, run using the alias given xp, and click on the active program desired to define with per-application settings. The results displayed will only be the information that Openbox itself requires, namely the WM_WINDOW_ROLE and WM_CLASS (name and class) values:
Many desktop environments and window managers support window snapping (e.g. Windows 7 Aero snap), whereby they will automatically snap into place when moved to the edge of the screen. This effect can also be simulated in Openbox through the use of keybinds on focused windows.
As illustrated in the example below, percentages must be used to determine window sizes (see openbox.org for further information). In this instance, The super key is used in conjunction with the navigation keys:
However, it should be noted that once a window has been 'snapped' to an edge, it will remain vertically maximised unless subsequently maximised and then restored. The solution is to implement additional keybinds - in this instance using the down and up keys - to do so. This will also make pulling 'snapped' windows from screen edges faster as well:
This Ubuntu forum thread provides more information. Applications such as opensnapAUR are also available to automatically simulate window snapping behaviour without the use of keybinds.Another option is to use bunsen-utilities-gitAUR which provides bl-aerosnap --left and bl-aerosnap --right commands which will snap active window on left or right edge respectively if it is not snapped and restore it to original size and position otherwise. Just bind these commands to the key combination of your choosing.
Users of display managers might experience a flickering during the transition between the display manager and the Openbox desktop. The flickering comes from Openbox setting the root window's color during startup. Therefore there is a brief moment when the display flashes in a grey color, between the display manager's background and the desktop's wallpaper.
Setting the root window's background color can be disabled by editing the Openbox startup script found in /usr/lib/openbox/openbox-autostart. Simply comment out (or delete) the block starting with # Set a background color.
If for any reason the newly extracted theme cannot be selected, open the theme directory to first ensure that it is compatible with Openbox - there should be an openbox-3 directory and a themerc file within it. An .obt (OpenBox Theme) file may also be present in some instances, which can then be manually loaded in obconf.
It seems openbox and xfwm are very popular around these parts, with openbox being the most popular. Any ideas as to why openbox is more popular? They're very similar projects - both written in C, similar LOC.
Frequently, when someone gets sick of gnome and kde's shenanigans, they get directed to LXDE, which uses openbox by default. As I recall, I skipped that stage and went directly to openbox on Ubuntu, after I saw a reference to it. I don't have much use for tiling, so openbox still does everything I need.
xfwm has it's own compositor, openbox doesn't.
I don't care about shadows and transparency so don't need any compositor
Also I've had problems with tearing when using compositors that went away when disabling the compositor.
I use Openbox because I like the total freedom to configure it to my likings, to choose what I want on the screen and where.
Openbox doesn't prevent to use Gnome or KDE applis as I prefer, or DE independent applis.
So it's perfect for me at the moment.
Openbox does sound good, and looking through the code it does look (slightly) cleaner than xfwm, although they're both really high quality projects, not often I find C code that feels kind of artisanal.
Honestly I never tried xfwm standalone. Openbox is extremely easy to setup, with just putting "exec openbox-session" in .xinitrc, putting the stuff you want to run in "$HOME/.config/openbox/autostart.sh" and just run from there.
Openbox can snap to corners. You just need to configure it. The strength of OB is that you can configure it to do nearly anything and look however you want. If you're just comparing OB's default behavior out-of-the-box (pun intended) then it would hardly measure up to any other WM.
To clarify, yep I'm talking about "aero" snap as seth suggested, where you can press mouse down on the titlebar, then drag the mouse to one of the corners in order to tile (as a quarter) into that corner. You can also drag to the top of the screen to maximize, or to the side of the screen to make it half the size of the screen. So not just edge snap but tiling.
ff7609af8f