goals:
openbox3 is supposed to be a wm shell, in that it offers a window management
  core, and you are able to make it look however you want by writing theme
  engines.

versioning:
im kinda thinking of openbox3 as being a product on its own, and then future
additions to it going as 3.x, instead of the crazy fast number system we've
adhered to so far. openbox4 would be an entirely new product as well. Maybe not
to the extent that 3 will be, but significantly different. If we ever even got
to that point, 3.x could live forever! :)

source heirarchy:
openbox3/
  rules/        architechture/platform specific Makefile rules
  po/           translations into every language known to man, even klingon!
  libob3/       classes which wrap obtool functionality, this is our toolkit (builds a separate .la)
  src/          the window manager
  util/	        utility classes/functions (Rect, itostring, etc)
  engines/      abstract interface and common code for the engines
    simple/     initial testbed. renders a simple hardcoded decroation style
    blackbox/   renders blackbox themes (bsetroot/bsetbg in here? no. fuck that)
    gl/         renders insane gl themes
    pixmap/     renders some sort of pixmap themes. a less generic name might
                be nice. (?)
    sawfish/    renders sawfish themes (?)
  gfxcore/      base gfx stuff for all to use (BColor, etc)
    gl/         code for drawing gl stuff
    pixmap/     code for drawing pixmaps

coding practices:
 braces for if's/etc's shall go like this:
     if () {
     }
   but, braces for funtions/classes/structs shall go like this:
     class foo
     {
     }
   and
     void func()
     {
     }
 thou shalt not 'cvs commit' without reading your 'cvs diff' first
 indentation: 2 spaces (NO TABS). just like the ob2 format.
 use const everywhere. pass pointer variables to functions as const.
 we will be using doxygen to build documentation for the source code. *every*
   function must have a doxygen comment for it.

misc:
 the libob external header(s) and the engine interface header need to be
   installed to the system include/ dir
 make sure that obtools can render things with the current engine!
 im going to write our own configure script! see if that works out. It will use
   the rules directory to support all these fun platforms.
 use GNU gettext for translation/nls support. See:
   http://www.gnu.org/manual/gettext/html_chapter/gettext_10.html#SEC141
 for its config, it will use $prefix/share/openbox/rc3 and ~/.openbox/rc3
 unsigned is the DEVIL. we will use signed variables EVERYWHERE. Xlib
   unsigned's should be converted to a signed long. If int isn't big enough
   for your data, than use a long.

src:
 everything will be event based. When you tell ob3 to add a workspace, it will
   simply send the client message the same way an external app does. This way
   there is only 1 code path for any process, not one for internally and one
   for externally generated actions.
 fuck workspace classes. all windows will exist in a screen list, and any per-
   workspace processing can be done by checking each window's workspace()
   value.
 in each screen, have a list of the windows on the currently visible workspace.
   This is updated when the workspace changes, or when windows are moved
   between workspaces.
 do we provide a callback interface from the plugins for when they catch mouse
   input on the decorations? we should make some way to make mouse input std
   across engines
 dockapp support as good as wmaker
 click-drag menus like wmaker/pwm/etc
 allow for 'session management' of a sort. let the wm remember a window's
   position/size/other attributes if they are saved by the user (window menu
   or something). this is especially important for dockapps to be cool
 on shutdown, first try to close each window with a normal close message. there
   should be a timeout for this, and then kill it hard after the timeout/with a
   dialog/whatever. This should be a separate option from normal exit, and
   it should not do this from catching a signal.
 for FocusIn/Out and Enter/LeaveNotify events, dont act on them immediately.
   Rather, save which window's focused/entered until the queue is empty, then
   if the focused/entered window has changed, act on it. This will be mad fast.
   Do the same for changing workspaces.
 keybindings. inside. final. god damn. i dont need 2 copies of the window
   manager running, one just grabbing keys.
 mouse gestures!
 resizing modes (support one of these)
   old style like now but without the server grab
   old style like now but creating windows which show the bars so no grab is
     needed
   opaque mode
   opaque mode where the frame resizes, and the client is resized aferwards (i
     dont like this)
 menus should have a most-recently or most-frequently chosen items section.

engines:
 each engine builds as a separate .so library. they are opened by the src/ and
   libob/ code.
 engines will be passed any number of screens, and must deal with them all with
   a single instance.
 engines must get events for most everything so they can be cool
 you can run a different engine on each screen (most people wont want GL on
   their second screen without accel!)
 engines are responsible for creating all of the appropriate decor windows
 engines must tell the wm how big the decorations are at all times and keep it
   updated for things like gravity.
 all engines will have to inherit from an abstract interface defined in the
   engines/ dir. there will be 2 abstact interfaces. the "lower power" mode,
   and the "full power mode". The engines must each inherit from both
   interfaces for the window manager and obtools to work.
 normally, an engine would setup the root window, window borders, timers, etc
   for everything involved in decorating windows. But also, it needs to be able
   to run in a slimmed mode that mostly consists of paintSurface() (the same
   way the menus are painted probably!). This would then be used by client
   apps like obtoolbar. These 2 modes are the "low power" and "full power"
   interfaces described above.

tool engine:
 FillSurface
 DrawBitmap (button pictures, such as X)

main engine:
 DecorateWindow
 etc :)