Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: source suggestings (was missing win32 file)
From: Greg Haerr (greg_at_censoft.com)
Date: 2002-06-12


> Unfortunately, we can't do that. The recorder and the player don't use the
same buttons:

> The player uses left/right (+/-) to advance in the directory list, while
the recorder uses up/down for the same functions. The recorder instead
uses left/right to enter/exit a directory or function, whereas the player
uses play/stop for this function.

I get it now. Geez. (I wouldn't have guessed that the two
Archos units operated differently)

> A good combination solution, I think, is to create such logical button
defintions on a file/module level, so that tree.c for instance defines and
uses BUTTON_NEXT locally. That removes the #ifdefs from the switch
statement and thus cleans it up considerably.

Yes, how about the follwing scheme: applications
buttons would be named APP_xxx, and low level
driver buttons would be named BUTTON_xxx.
In the simple case, the low level driver for either
recorder or player could just return the APP_xxx values
for small code size using the following in drivers/button.c:

#define BUTTON_UP APP_PLAY

This might need a bit more thought, but it would be
nice to remove the #ifdefs from most of the apps code...

> Sure. Consolitating the init just means creating a number of stubs for the
target init calls, which isn't much of a problem.

An idea here would be to not reuquire any firmware/*.c
code in the simulator, except for some very basic
init_xxx() functions, which would be defined in both
firmware/ and uisimulator/ directories, suited for
either target, x11, or win32 init. So in other
words, the code in apps/main.c:init() would be moved
to say, firmware/kernel.c

Regards,

Greg

--
Björn



Page was last modified "Jan 10 2012" The Rockbox Crew
aaa