this is so old..
This commit is contained in:
parent
3f446e917d
commit
fdd18551ee
6 changed files with 0 additions and 85 deletions
BIN
DESIGN/glue.dia
BIN
DESIGN/glue.dia
Binary file not shown.
|
@ -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.
|
Binary file not shown.
|
@ -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
|
Binary file not shown.
Loading…
Reference in a new issue