Frank Gevaerts wrote:
On Sun, May 16, 2010 at 02:23:36PM +0100, Dave Chapman wrote:
I don't really think the simulator can use much more core rockbox code
without becoming an emulator.
I'm not saying that the uisim can use more Rockbox code, just that RaaA
should use less, and that over time, the difference between the two will
grow.
I'm also not convinced that changing some #ifdef SIMULATOR lines to use
things like HAVE_SDL or HAVE_SDL_AUDIO makes the code for the simulator
better. IMO it makes it harder to see the places where the sim differs
from the target it's simulating (it still differs in the same way, it's
just obfuscated more).
Is it obfuscated more, or just obfuscated *differently*?
It's now obfuscated in multiple ways (different #ifdefs), instead of the
old single #ifdef SIMULATOR way.
Simulating buttons exactly is indeed a real concern, but I'd argue that
the target-tree arrangement is *better* for that, since it's now
actually easy to e.g. take button-sdl.c, make a copy somewhere called
button-x5-sdl.c, and have that one simulate real hardware constraints.
The target tree provides a clean way to organise this, while I think the
old uisimulator/ structure didn't.
I agree that the uisimulator can be improved, and maybe putting it in
the target tree is the right solution. I am just not convinced that
this should be confused with RaaA - i.e. improve the sim independently
of RaaA.
For example, another way to improve the sim button handler would be to
have a higher-level data structure which describes the buttons of the
device, and a generic simulator SDL button driver that uses that data
structure to simulate the hardware.
There will still be common parts though, and I think those really should
be common.
I'm not saying this won't be the case, but my feeling is that these will
be small, and
Similarly, the LCD code for the sim presents the main LCD, the remote
LCD (if present on the target), a backdrop image, simulation of
backlights, simulation of charcell etc. For RaaA, none of those
complications are needed, but different complications may be - such as
possible window resizing, or run-time detection of LCD size (if we go
all the way with RaaA), or other things we haven't thought of yet.
I won't repeat what I said for buttons, but I believe this is indeed
similar.
I disagree - the LCD code between the sim and RaaA will differ even
more different than the button code...
Am I missing something obvious? Why is putting the sim code in target
tree a good idea?
Why isn't it? I can see some important advantages (like not duplicating
code, making it easy to have target-specific hosted drivers for *both*
RaaA and the simulator), and to be honest, I don't agree with the
disadvantages you point out (I think they're either just changes that
don't make things worse, just different, or very minor).
I think it just boils down to my view that I don't want RaaA to be the
same as the simulator. It seems to be a common view that they should
share code, but I would want to see the simulator move in a different
direction to RaaA, so would want to keep the code as independent as
possible, at least during these early stages.
Dave.
