Fred | 21 Jul 14:37 2014

problem building OB from tarball


I want to use Openbox with Debian 7.5 on a Sun Ultra 5.  The compile 
seemed to go ok but OB complains of not being able to find and then exits.  This library is in /usr/lib64 as it 
is supposed to be according to the OB build instructions on the website.

Best regards,

openbox mailing list
openbox <at>
Ian Zimmerman | 16 Jul 01:54 2014

Omnipresence lost mvoing to another desktop

Is this a bug?  When I drag a window that has the "all desktops" flag
set, dragging to a different desktop is enabled, and I do accidentally
cross over to a different desktop, suddenly the window is _only_ on the
destination desktop (ie. the "all desktops" setting seems to be

To be honest, I don't really know what should happen in this situation.
Probably not 2 copies of the same window on the destination desktop ...


Please *no* private copies of mailing list or newsgroup messages.
openbox mailing list
openbox <at>
Lukasz Grabowski | 9 Jul 16:14 2014

hide from taskbar but not from window switcher


Is it possible to hide a specific application from the tint2 taskbar
but not from the openbox window switcher? I tried experimenting with
the rc.xml options skip_pager and skip_taskbar but  they don't seem to
allow for that.

My motivation is to have one firefox window open all the time on all
desktops. I'd like to be able to swich to it using alt-tab, but since
I have it open all the time there's no need to show it in the taskbar.

Best, Lukasz
openbox mailing list
openbox <at>
E R | 9 Jul 08:20 2014

No decor for mpv not working


By chance anyone using mpv and can make it work with no decor?

This is not working for me in 3.5.2 with mpv 0.4.0

xprop | grep WM_CLASS gives me;

WM_CLASS(STRING) = "gl", "mpv"

This is what I have in my rc.xml;

<!-- Center application windows -->
    <application name="feh">
      <position force="yes">
    <!-- End center of application windows -->
    <!-- No decor for application windows -->
    <application name="mpv">
    <!-- End decor for application windows -->

I'm using SpaceFM in Openbox and if I change the name to <application name="spacefm"> it works, so something is going on with it not working with mpv.

openbox mailing list
openbox <at>
Lukasz Grabowski | 25 Jun 01:12 2014

customizing window switcher


I use the vertical window switcher (i.e. a list of window titles.) Is
it possible to make it wider?

Rationale: I usually have 5-6 different zathura sessions, each one has
window title of the sort "/home/luke/Dropbox/articles/John Smith -
very important but obscure title.pdf".
It is somewhat frustrating  that most of the time the title I see in
the window switcher is "/home/luke/Dropbox/articles/J...tle.pdf". So
for me switching windows in openbox is more or less a guessing game
right now.

I've already changed the font to 7 via (In)ActiveOnScreenDisplay  in
rc.xml but it isn't helping a lot.

Best, Lukasz
openbox mailing list
openbox <at>
Mindaugas B | 5 Jun 08:12 2014

Re: Switching to console does not work.

It looks at the end that it is related to startx not with openbox related.

video card :
00:02.0 VGA compatible controller: Intel Corporation Device 0be2 (rev 0b)

consoles running:
 805 tty4     Ss+    0:00 /sbin/getty -8 38400 tty4
  809 tty5     Ss+    0:00 /sbin/getty -8 38400 tty5
  814 tty2     Ss+    0:00 /sbin/getty -8 38400 tty2
  816 tty3     Ss+    0:00 /sbin/getty -8 38400 tty3
  818 tty6     Ss+    0:00 /sbin/getty -8 38400 tty6
 1019 tty1     Ss+    0:00 /sbin/getty -8 38400 tty1
no /etc/inittab file
but i have  default runlevel /etc/init/rc-sysinit.conf:

also i use config in these files, this launch startx on tty8:

contents of file tty8.conf:
# tty8 - getty
# This service maintains a getty on tty8 from the point the system is
# started until it is shut down again.

start on stopped rc RUNLEVEL=[2345]
stop on runlevel [!2345]

exec /bin/openvt -fwc8 -- /usr/bin/sudo -H -u user /usr/bin/startx

in user profile folder there is .Xsession witch launch openbox

# start idesk, icons on desktop
/usr/bin/idesk &


openbox mailing list
openbox <at>
Aleksandrina Nikolova | 3 Jun 15:21 2014

Wiki access

I am requesting access to edit the wiki. I'd like to contribute in any way I can. Right now I have a pipe menu (with the idea of creating more) that I'd like to upload to

My username is AaylaSecura

Please add me to the Person group:

Thank you!
openbox mailing list
openbox <at>
E R | 2 Jun 11:02 2014

Openbox Development Where Is It?

Hello All,

First let me say to all those involved and I truly don't know if Dana is the only one developing here, but if not, then thanks to all involved.

I've been around using Openbox since it began and I personally think it's the best.

But here's the sad reality, yes? It seems like there hasn't been any commits in 6 months, many bugs not answered or fixed, so what is happening to the life of this project, why is life for Openbox going so slow, is it dying out?

Please don't let commits go so long and slow, is there any hope to getting more activity on Openbox?

Sorry I'm not a coder, or I'd be right there helping...

Thank you
Mii Bolen

openbox mailing list
openbox <at>
Aleksandrina Nikolova | 28 May 19:38 2014

Disabling actions for certain windows matched by their name (or otherwise)

Greetings! I recently installed Openbox for the first time and am in the process of configuring it. I run it on its own without any DE. I am trying to prevent certain windows (matched by name or whatever) from closing, minimizing, resizing, etc via the keybindings (Alt+F4, etc). I couldn't figure out a way to use such conditional statements in the keybindings section; the only example of such I have seen is of the form "if window is shaded or minimized or...", not "if window name is...". I tried doing this with xprop by running:


to only allow these windows to be placed below others, but openbox seems to ignore this completely. Furthermore, when I close the window and reopen it, it emerges with the same id as before, but my changes are reset to their default values (that allow all actions for this window). I also tried removing the property WM_PROTOCOLS using xprop again, that is supposed to tell openbox not to manage this window at all as far as I could understand. Still no luck... Any ideas?
If it's of any importance, I start openbox with:

exec ck-launch-session dbus-launch --sh-syntax --exit-with-session openbox-session
openbox mailing list
openbox <at>
Cade Foster | 26 May 07:41 2014

Wiki access

I am requesting access to edit the wiki.

My username is: Cade Forester

Please add me to the Person group:

Thank you!
openbox mailing list
openbox <at>
Carlos Pita | 5 May 18:57 2014

SwapGeometry (proposal)

Hi all,

I tend to use Grow/Shrink/MoveToEdge actions a lot to get some
pseudo-tiling inside openbox, coupled with MoveResizeTo and some
preset geometries I use the most. But then I would like to be able to
restore some "normal" geometry after "tiling" a bit, because what I
always hated of tilers is how they force some layout oriented to see N
things at the same time (I'm admittedly already at grips with N=2)
when it's not the use case at hand. Ranting aside, I would like to
restore some "normal" geometry after the resize excursion, as I've
already said.

So I came up with a simple swapgeom python+xpybutils script (which
could also have been implemented using an appropriate combination of
xprop, xdotool and wmctrl, I guess) that saves the geometry of the
currently focused client and restores the previously saved geometry,
if any. The typical use case for me is to save the initial geometry of
a window and then think of it as the normal mode and of the
alternative geometry as the tiled mode. Then I move-resize the client
to the contents of my heart when in tiled mode, knowing that I've
backed up the preferred geometry for the time when stacking comes

This swapgeom thing (attached), as it's currently implemented, relies
a lot on ewmh/netwm and, since it must detect the maximized state of a
client and return it to unmaximized before saving the geometry, there
is some unpleasant visible sequence of window manager actions while
the swap takes place (unmaximize, save geometry, restore previous
geometry, retore previous maximized state).

So I would like to implement it as an action, say SwapGeometry, which
will work on the currently client simply saving some structured data
like { prev_x, prev_y, prev_w, prev_h, prev_maxh, prev_maxv } and
restoring the previously saved one, if any.

Do you think this could be of general enough interest to be included
as part of openbox? I think it's a nice complement to the
pseudo-tiling support openbox already has. The dynamism these
Grow/Shrink/MoveToEdge and MoveResizeTo actions offer feels a bit
crippled when there is no way to switch back and forth between some
geometries. As it stands my solution is pretty simple, I deliberately
avoided keeping a history of geometries or backing up entire desktop
layouts. Instead, it's more of a Undo/Redo toggle. But I would like to
hear some opinions from you.

Best regards
Attachment (swapgeom): application/octet-stream, 2265 bytes
openbox mailing list