On Sun, May 16, 2010 at 02:23:36PM +0100, Dave Chapman wrote:
> pouly amaury wrote:
>> What do you think about it? Do you have any ideas how my proposal
>> could be improved? Or do you have any questions? Please join the
>> Sounds ok for me, I like the idea of the simulator being a real target.
> Apologies for answering so late (too late in a way, as this patch was
> committed yesterday), but the concept of the simulator being a real
> target worries me. This is simply because the simulator *isn't* a real
> target - it's a simulation of a real target.
> My understanding of the purpose of RaaA is that it would use less and
> less of the Rockbox firmware code as time went on. Development of the
> sim should go in the opposite direction - using more and more Rockbox
I don't really think the simulator can use much more core rockbox code
without becoming an emulator.
> 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*?
> As an example of the different purposes of the sim and RaaA, the SDL
> button driver for RaaA should expose all buttons to the apps/ part of
> Rockbox (especially if there is a full keyboard on the device). The SDL
> button code for the sim should (although it doesn't currently) provide
> simulation of the hardware buttons (and/or touchscreen and remote) on
> the real device, including things like mechanical and electrical
> limitations. Other buttons are used for events such as USB
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.
There will still be common parts though, and I think those really should
> 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
> 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 would have preferred to have seen a new SDL target being added to the
> target tree, with none of the sim code in it - i.e. a shiny new SDL
> target without the baggage of the sim, and leaving the sim free to be
> developed and improved independently of RaaA (and in the opposite
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
Received on 2010-05-16