DESIGN/thoughts

   1 goals:
   2 openbox3 is supposed to be a wm shell, in that it offers a window management
   3   core, and you are able to make it look however you want by writing theme
   4   engines.
   5
   6 versioning:
   7 im kinda thinking of openbox3 as being a product on its own, and then future
   8 additions to it going as 3.x, instead of the crazy fast number system we've
   9 adhered to so far. openbox4 would be an entirely new product as well. Maybe not
  10 to the extent that 3 will be, but significantly different. If we ever even got
  11 to that point, 3.x could live forever! :)
  12
  13 source heirarchy:
  14 openbox3/
  15   rules/        architechture/platform specific Makefile rules
  16   po/           translations into every language known to man, even klingon!
  17   libob3/       classes which wrap obtool functionality, this is our toolkit (builds a separate .la)
  18   src/          the window manager
  19   util/         utility classes/functions (Rect, itostring, etc)
  20   engines/      abstract interface and common code for the engines
  21     simple/     initial testbed. renders a simple hardcoded decroation style
  22     blackbox/   renders blackbox themes (bsetroot/bsetbg in here? no. fuck that)
  23     gl/         renders insane gl themes
  24     pixmap/     renders some sort of pixmap themes. a less generic name might
  25                 be nice. (?)
  26     sawfish/    renders sawfish themes (?)
  27   gfxcore/      base gfx stuff for all to use (BColor, etc)
  28     gl/         code for drawing gl stuff
  29     pixmap/     code for drawing pixmaps
  30
  31 coding practices:
  32  braces for if's/etc's shall go like this:
  33      if () {
  34      }
  35    but, braces for funtions/classes/structs shall go like this:
  36      class foo
  37      {
  38      }
  39    and
  40      void func()
  41      {
  42      }
  43  thou shalt not 'cvs commit' without reading your 'cvs diff' first
  44  indentation: 2 spaces (NO TABS). just like the ob2 format.
  45  use const everywhere. pass pointer variables to functions as const.
  46  we will be using doxygen to build documentation for the source code. *every*
  47    function must have a doxygen comment for it.
  48
  49 misc:
  50  the libob external header(s) and the engine interface header need to be
  51    installed to the system include/ dir
  52  make sure that obtools can render things with the current engine!
  53  im going to write our own configure script! see if that works out. It will use
  54    the rules directory to support all these fun platforms.
  55  use GNU gettext for translation/nls support. See:
  56    http://www.gnu.org/manual/gettext/html_chapter/gettext_10.html#SEC141
  57  for its config, it will use $prefix/share/openbox/rc3 and ~/.openbox/rc3
  58  unsigned is the DEVIL. we will use signed variables EVERYWHERE. Xlib
  59    unsigned's should be converted to a signed long. If int isn't big enough
  60    for your data, than use a long.
  61
  62 src:
  63  everything will be event based. When you tell ob3 to add a workspace, it will
  64    simply send the client message the same way an external app does. This way
  65    there is only 1 code path for any process, not one for internally and one
  66    for externally generated actions.
  67  fuck workspace classes. all windows will exist in a screen list, and any per-
  68    workspace processing can be done by checking each window's workspace()
  69    value.
  70  in each screen, have a list of the windows on the currently visible workspace.
  71    This is updated when the workspace changes, or when windows are moved
  72    between workspaces.
  73  do we provide a callback interface from the plugins for when they catch mouse
  74    input on the decorations? we should make some way to make mouse input std
  75    across engines
  76  dockapp support as good as wmaker
  77  click-drag menus like wmaker/pwm/etc
  78  allow for 'session management' of a sort. let the wm remember a window's
  79    position/size/other attributes if they are saved by the user (window menu
  80    or something). this is especially important for dockapps to be cool
  81  on shutdown, first try to close each window with a normal close message. there
  82    should be a timeout for this, and then kill it hard after the timeout/with a
  83    dialog/whatever. This should be a separate option from normal exit, and
  84    it should not do this from catching a signal.
  85  for FocusIn/Out and Enter/LeaveNotify events, dont act on them immediately.
  86    Rather, save which window's focused/entered until the queue is empty, then
  87    if the focused/entered window has changed, act on it. This will be mad fast.
  88    Do the same for changing workspaces.
  89  keybindings. inside. final. god damn. i dont need 2 copies of the window
  90    manager running, one just grabbing keys.
  91  mouse gestures!
  92  resizing modes (support one of these)
  93    old style like now but without the server grab
  94    old style like now but creating windows which show the bars so no grab is
  95      needed
  96    opaque mode
  97    opaque mode where the frame resizes, and the client is resized aferwards (i
  98      dont like this)
  99  menus should have a most-recently or most-frequently chosen items section.
 100
 101 engines:
 102  each engine builds as a separate .so library. they are opened by the src/ and
 103    libob/ code.
 104  engines will be passed any number of screens, and must deal with them all with
 105    a single instance.
 106  engines must get events for most everything so they can be cool
 107  you can run a different engine on each screen (most people wont want GL on
 108    their second screen without accel!)
 109  engines are responsible for creating all of the appropriate decor windows
 110  engines must tell the wm how big the decorations are at all times and keep it
 111    updated for things like gravity.
 112  all engines will have to inherit from an abstract interface defined in the
 113    engines/ dir. there will be 2 abstact interfaces. the "lower power" mode,
 114    and the "full power mode". The engines must each inherit from both
 115    interfaces for the window manager and obtools to work.
 116  normally, an engine would setup the root window, window borders, timers, etc
 117    for everything involved in decorating windows. But also, it needs to be able
 118    to run in a slimmed mode that mostly consists of paintSurface() (the same
 119    way the menus are painted probably!). This would then be used by client
 120    apps like obtoolbar. These 2 modes are the "low power" and "full power"
 121    interfaces described above.
 122
 123 tool engine:
 124  FillSurface
 125  DrawBitmap (button pictures, such as X)
 126
 127 main engine:
 128  DecorateWindow
 129  etc :)