+++ /dev/null
-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.
+++ /dev/null
-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
projects / chaz / openbox / commitdiff
