this file is so old it's scary
This commit is contained in:
Mikael Magnusson
parent
a4a6d1bae1
commit
4f1b53be2b
1 changed files with 0 additions and 129 deletions
129
DESIGN/thoughts
129
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 :)
|
||||
Loading…
Reference in a new issue