On Thu, 22 Jun 2006, RaeNye wrote:
Several scriptable elements currently exist (WPS, .cfg files -- including
themes) but a more powerful language will enable RB to do much more,
including:
This would require some rather drastic changes.
- scheduled tasks (much more than "sleep after 10 idle minutes")
... and it would require that we can start scripts (in the background) on a
given time.
- configurable menus and button assignment. This needs some basic redesign,
but once we move to generic events (i.e., MENU_BACK instead of #ifdef ....
BUTTON_XXX) it's rather simple
... and it would require that we run scripts for each button, or at least
allow scripts to be run that way.
- much richer WPS options (no more "you need these 7 specialized patches to
run this WPS")
Are you suggesting the WPS screen would be drawn with the help of a scripting
language then? It would certainly make them a lot harder to make for the
average user.
Also, I would expect that to be more resource hungry both in terms of memory
and CPU (== less run-time).
I suggest lua (www.lua.org, OS and free for all uses, last version: 5.02)
which combines powerful structure (OOP, functional programming, etc.) with a
low memory footprint (on x86: 100K/lua core, 100K/std. library - less than
most codecs).
If we would, it could hardly run on Archos and then we need to maintain
ability to run Rockbox entirely without this scripting option.
To compile this we mostly need some dynamic memory allocation scheme
(realloc() -compatible)
Ugha. But sure, if this scripting idea is deemed to be a super-good idea, we
could of course provide a tiny little memory pool and malloc to be used by the
scripting language only.
(I *will* ignore comments mentioning the feature freeze or version 3.0)
Let me put it this way instead:
By not working on fixing the actual current problems we have and instead
working on new post-3.0 features, we'll just get a longer feature freeze
period.
--
Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
