]> icculus.org git repositories - mikachu/openbox.git/blob - DESIGN/thoughts
missed setting 'current' at the end of the pyramid gradient
[mikachu/openbox.git] / 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 :)