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