@@ -0,0 +1,129 @@ 
+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 :)