this is so old..

This commit is contained in:
Dana Jansens 2007-05-12 18:44:23 +00:00
parent 3f446e917d
commit fdd18551ee
6 changed files with 0 additions and 85 deletions

Binary file not shown.

View file

@ -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.

View file

@ -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.

View file