From: Dana Jansens Date: Sat, 18 Jan 2003 05:58:56 +0000 (+0000) Subject: add DESIGN from the openbox3 repository. add to that the render.dia, a design diagram... X-Git-Url: https://git.brokenzipper.com/gitweb?a=commitdiff_plain;h=e2607f616d8ab2abd494af74f0a53de7c658110f;p=chaz%2Fopenbox add DESIGN from the openbox3 repository. add to that the render.dia, a design diagram for the new render code --- diff --git a/DESIGN/ob3arch.png b/DESIGN/ob3arch.png new file mode 100644 index 00000000..31c76c94 Binary files /dev/null and b/DESIGN/ob3arch.png differ diff --git a/DESIGN/render.dia b/DESIGN/render.dia new file mode 100644 index 00000000..938e4122 Binary files /dev/null and b/DESIGN/render.dia differ diff --git a/DESIGN/roadmap b/DESIGN/roadmap new file mode 100644 index 00000000..e69de29b diff --git a/DESIGN/thoughts b/DESIGN/thoughts new file mode 100644 index 00000000..b7de0ad0 --- /dev/null +++ b/DESIGN/thoughts @@ -0,0 +1,129 @@ +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 :)