D DESIGN/thoughts

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