From: Dave Chapman <dave_at_dchapman.com>
Date: Sun, 16 May 2010 15:18:58 +0100

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.
Received on 2010-05-16