From: Greg Haerr <greg_at_censoft.com>
Date: Wed, 12 Jun 2002 02:05:47 -0700

> 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

Received on 2002-06-12