From: Mikael Magnusson Date: Sat, 27 Mar 2004 21:21:09 +0000 (+0000) Subject: this file is so old it's scary X-Git-Url: https://git.dogcows.com/gitweb?a=commitdiff_plain;h=4f1b53be2b29d4dea5d1902908a73ae3f53074d4;p=chaz%2Fopenbox this file is so old it's scary --- diff --git a/DESIGN/thoughts b/DESIGN/thoughts deleted file mode 100644 index b7de0ad0..00000000 --- a/DESIGN/thoughts +++ /dev/null @@ -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 :)