--- /dev/null
+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 :)