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
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! :)
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
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
32 braces for if's/etc's shall go like this:
35 but, braces for funtions/classes/structs shall go like this:
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.
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.
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()
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
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
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.
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
97 opaque mode where the frame resizes, and the client is resized aferwards (i
99 menus should have a most-recently or most-frequently chosen items section.
102 each engine builds as a separate .so library. they are opened by the src/ and
104 engines will be passed any number of screens, and must deal with them all with
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.
125 DrawBitmap (button pictures, such as X)