• AlanD
  • #! Member
  • Offline
  • Registered: 2011-05-12
  • Posts: 65

Topic: the perimeter of openbox

A friend and I were discussing DEs and I figured it would be nice to know just what the extents of OB is, in terms of its resources, files, applications. A DE seems pretty integrated into a system and its hard for a neophyte to get a good grasp of what it comprises of.

So I guess I am asking for help to understand whats going on when openbox is installed, and what it affects. I'd like to be able to say "thats part of OB and that isnt". I'm less interested in the DE user apps in the sense that say, gnome has gedit for a text editor, gcalc, a browser, etc.

I chose OB because thats why I am using, its lightweight, and there is less clutter since it doesnt have a panel for instance. Am I actually asking a valid question that isnt too immense in scope?

I've compiled a few apps and recently learned about patching, diff, git and svn from the openhatch site, so I guess this is the next step I want to take.

Help please?

  • Unia
  • #! Die-hard
  • Offline
  • From: The Netherlands
  • Registered: 2010-07-17
  • Posts: 2,304

Re: the perimeter of openbox

Well, Openbox is just a window manager. That means it just manages your windows, nothing else/more. It does give you an autostart script to automatically launch applications and it gives you a menu too (as you probably know already), but that's really it AFAIK.

EDIT: Do you want to know its files too? You can find some in /usr/bin I think, if that's what you were after.

Last edited by Unia (2011-06-04 18:57:22)

Let's do it and don't screw it.
      Github || Deviantart
  • AlanD
  • #! Member
  • Offline
  • Registered: 2011-05-12
  • Posts: 65

Re: the perimeter of openbox

Thanks for the quick reply Unia.

Thats a good point. I used the wrong terminology.

So it is quite simple indeed then. I'm interested in how it interacts with the system as a whole. I know I can just check the build dependencies, but I'm trying to see how it all fits together. As a visual sort of guy I'm interested in mapping it in my mind.

I'll have a look in /usr/bin. Hopefully I can come to some understanding that will let me ask a more valid question, something with some direction.

  • Registered: 2011-02-04
  • Posts: 111

Re: the perimeter of openbox

You can get a pretty accurate idea of what OB does by looking at the kinds of things you can change with obconf. 

And also at the things you can change about a window with your mouse. (Size, location, overlap, etc.)

You can see how OB fits into a running system by looking at pstree output. I don't have a #! system in front of me at the moment, so you may have to do this first:

apt-get install psmisc

Looking at pstree, you can see who starts OB, who is started by OB, and so on.

Reading the "window manager" and "desktop environment" pages at Wikipedia will help some as well.

tranche's Website

  • From: California, USA
  • Registered: 2008-11-29
  • Posts: 8,647

Re: the perimeter of openbox

Openbox is just a window manager. Its config files are few:

etc/xdg/openbox/autostart.sh
etc/xdg/openbox/menu.xml
etc/xdg/openbox/rc.xml

And heres the executables it installs (on Arch anyways):

usr/bin/gdm-control
usr/bin/gnome-panel-control
usr/bin/obxprop
usr/bin/openbox
usr/bin/openbox-gnome-session
usr/bin/openbox-kde-session
usr/bin/openbox-session

And it has the typical man pages, locales, a few themes but not much else.

It has no panel included and obconf is a separate download.

Note: ** Please read before posting **

BTW if you wish to contact me, send me an e-mail instead of a PM.
  • AlanD
  • #! Member
  • Offline
  • Registered: 2011-05-12
  • Posts: 65

Re: the perimeter of openbox

anonymous, that list of installed apps is exactly the sort of thing I was looking for. Its interesting to see that it uses that gnome stuff. I suppose there will be some movement to get away from that by the OB maintainers due to gnome 3.0 and unity. I know that is why i left ubuntu/mint.

I've been using OB for a few weeks now and I have a good feel for the configs. I like how the editing is accessible. There were things I wanted to change in gnome that were not exactly straight forward. For instance, changing the apps/places/system text was a bit of a hack using locales. OB is much easier to dig into and there is a lot less to dig through.

I'm curious about the backside of the scenery, so to speak. I can see the desktop and I can read the source. I can fiddle with the configs so I was wondering what other views I can get of the action.


Thus, pstree looks very helpful. I will get reading at wikipedia too. Thank you tranche. Thank you anonymous.

Last edited by AlanD (2011-06-04 20:06:55)

  • From: California, USA
  • Registered: 2008-11-29
  • Posts: 8,647

Re: the perimeter of openbox

Well the openbox-gnome-session file was just to allow users to login to Gnome but with Openbox as the window manager. Personally I never tried it and I doubt it work with the new Gnome 3.0.

Note: ** Please read before posting **

BTW if you wish to contact me, send me an e-mail instead of a PM.
  • Awebb
  • #! Die-hard
  • Offline
  • Registered: 2009-07-23
  • Posts: 2,471

Re: the perimeter of openbox

I'm still not sure whether I know what you want. Openbox manages the windows inside an X11 session. It communicates with the X server, telling it where and how to draw the windows and what to do with the window, when user interaction happens.

While an X session is running, almost all user inputs are relayed to and interpreted by the X server. The X server knows what the gfx card needs to know to draw the windows and it knows what the window manager needs to be informed about concerning user inputs.

Openbox also provides a session and is the shell for this session. I leave it to your google skills to find out what shell means here. A session basically is just a process that signals the system that the X server is still needed (or the display manager that he shouldn't be active). In addition, Openbox provides it's own autostart sequence (basically a script that runs when the session starts), a hotkey manager (whenever the X server submits a key event, it is checked against your list of hotkeys in the config file to figure out what to do) and a launcher menu. All those things aren't very close to the unix philosophy (one single task per one single application), but the hell I care as long as it works as well as it does.

If you really want to know what happens backstage, learn how the X.Org API works.

I'm so meta, even this acronym
  • AlanD
  • #! Member
  • Offline
  • Registered: 2011-05-12
  • Posts: 65

Re: the perimeter of openbox

Awebb wrote:

I'm still not sure whether I know what you want. Openbox manages the windows inside an X11 session. It communicates with the X server, telling it where and how to draw the windows and what to do with the window, when user interaction happens.

Thats ok. I am sorta shooting in the dark too. But everyones replies have been informative, and I am learning.

While an X session is running, almost all user inputs are relayed to and interpreted by the X server. The X server knows what the gfx card needs to know to draw the windows and it knows what the window manager needs to be informed about concerning user inputs.

So the WM provides some form to the x session, which does the drawing making use of the graphics drivers routines, and the graphics cards hardware, if applicable. If I understand.

Openbox also provides a session and is the shell for this session. I leave it to your google skills to find out what shell means here. A session basically is just a process that signals the system that the X server is still needed (or the display manager that he shouldn't be active). In addition, Openbox provides it's own autostart sequence (basically a script that runs when the session starts), a hotkey manager (whenever the X server submits a key event, it is checked against your list of hotkeys in the config file to figure out what to do) and a launcher menu. All those things aren't very close to the unix philosophy (one single task per one single application), but the hell I care as long as it works as well as it does.

The session controls whether to use gnome, kde, OB, something else, or just a plain old CLI then. Ok.

I too dont care about the philosophy aspect: it seems that because these are disparate pieces, it becomes easier to understand their individual domains. I want to understand what is inside the *box, and thats easier if its not a monolith.

If you really want to know what happens backstage, learn how the X.Org API works.

I will add that to my list. Thanks.