From: Dana Jansens Date: Sat, 12 May 2007 18:44:23 +0000 (+0000) Subject: this is so old.. X-Git-Url: https://git.brokenzipper.com/gitweb?a=commitdiff_plain;h=fdd18551ee2e47a3e49fce4deb581af07681a15c;p=chaz%2Fopenbox this is so old.. --- diff --git a/DESIGN/glue.dia b/DESIGN/glue.dia deleted file mode 100644 index 84afda33..00000000 Binary files a/DESIGN/glue.dia and /dev/null differ diff --git a/DESIGN/menu-thoughts.txt b/DESIGN/menu-thoughts.txt deleted file mode 100644 index b94e9305..00000000 --- a/DESIGN/menu-thoughts.txt +++ /dev/null @@ -1,29 +0,0 @@ -Okay Soldiers, here's the plan: -menu.c contains functions for handling a menu list. This may have to -be turned into an array. -The invalid bit denotes whether the menu must be rerendered. Normally, -it is auto-managed by the menu.c functions. - -Each menu has a set of controller functions that handle behaviour: - show() - place a menu on screen - also, may rerender the menu if the invalid bit is set - hide() - hide a menu - mouseover() - called when the mouse moves over a new entry - may highlight new entry and display submenu - selected() - called when an item is clicked on - may execute, change config options?, perform action, or - display submenu - update() - re-render the menu - -When a menu is rerendered, the engine can place any information like -(x,y) coordinates, appearances &c in the renderdata. - -To customize the behaviour of a menu, set the controller function -pointers. Some ideas: - - we can have plugins for PipeMenus, FIFOMenus, ConfigMenus, Toolbar, - &c. - - a TimedUpdate menu (say for mp3 lists) could call update() - periodically. - - window lists/workspace menus need to be optimized somehow since - these change often, and modifying the list that often will be - crap. needs profiling. diff --git a/DESIGN/ob3arch.png b/DESIGN/ob3arch.png deleted file mode 100644 index 31c76c94..00000000 Binary files a/DESIGN/ob3arch.png and /dev/null differ diff --git a/DESIGN/plugins_vs_scripting.txt b/DESIGN/plugins_vs_scripting.txt deleted file mode 100644 index a569240a..00000000 --- a/DESIGN/plugins_vs_scripting.txt +++ /dev/null @@ -1,56 +0,0 @@ -So I had a bit of a rant and thought I'd save it... - - -* xOr figures python wont last for ob4, but we'll see -(xOr) since theres only so much you can do -(xOr) and some added config files/c code can do it all -(xOr) i mean, realisticly, how many people are going to make .py's -(xOr) theyre going to ask me for a new feature -(xOr) they wont write a py -(xOr) so a clean and smart c kernel with sub modules of C code would - probly be more optimal eventually -(xOr) scripting was cool for gnus, but i wished i could just set it (mutt) -(shrimpx) .so's would be cool in the absence of scripting, prolly -(xOr) yea thats what im meaning -(xOr) like engines, but for functions -(xOr) so youd replace bbappconf witha .so that can interact properly -(xOr) and you dont have to write all this crazy Python/c at all and you - end up with something easier to configure -(xOr) with less effort -(@xOr) also less room for pregnancy [strong typing is good] with all C -(@xOr) and less 'my python script wont load, tteach me python xor' -(@xOr) what i figure would happen over slow evolution course is.. -(@xOr) python modules would be converted to python/c inline shit -(shrimpx) xOr: you know that some wacko is going to embed python in an .so -(@xOr) shrimpx: and itd probly be better -(@xOr) shrimpx: cuz it would do less stuff -(shrimpx) less stuff == less defensive programming against moron - extension programmers -(@xOr) yea -(@xOr) and less to try learn to use it -(@xOr) and less to screw up -(@xOr) and for instance, if we were to look at emacs, which is the - probably most popular scripted application -(@xOr) my .emacs is not crazy code -(@xOr) its some keybindings -(@xOr) and setting variables -(shrimpx) yah but 99% of emacs functionality is in lisp -(@xOr) ya -(@xOr) but thats not a reason to use it -(@xOr) or a reason why its good -(@xOr) thats just the language of implementation -(shrimpx) even tho it's not .rc -(@xOr) its good because entensions are written in the same language as - its implementation -(@xOr) do vim plugins have access to the same amount of internals as - emacs entensions? -(shrimpx) no -(@xOr) right -(@xOr) this i think is why emacs is better than vim -(@xOr) youcan write a crazy dope cvs.el -(@xOr) you can write shell.el -(@xOr) you cant do these with vim -(@xOr) you can make hackish addons with keybindings -(@xOr) so if openbox has .so plugins, its equally as good for exteding as - with python extensions -(@xOr) possibly better because you can access more diff --git a/DESIGN/render.dia b/DESIGN/render.dia deleted file mode 100644 index de912a52..00000000 Binary files a/DESIGN/render.dia and /dev/null differ diff --git a/DESIGN/roadmap b/DESIGN/roadmap deleted file mode 100644 index e69de29b..00000000