Thomas Martitz wrote:
>> 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
> No, I don't think RaaA aims to use less and less Rockbox code. It's a
> port of Rockbox afterall.
I said "Rockbox firmware code". So what _is_ RaaA if it's not about
using less Rockbox code than a "real" Rockbox ?
>> 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).
Can you respond to this?
>> 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
> That's not going to change. The parts that are simulating a target
> override the SDL app parts, e.g. by including a different
> button-target.h. We never simulated mechanical and electrical
> limitations and that's not going to change.
Why is that not going to change? Who decided that wasn't a desirable
feature of the sim?
> We want to run code which
> compiles for a target on a more convinient system (simulate), not
> emulate the target itself.
Are you talking about RaaA or the UI simulator? IMO, the ideal UI
simulator would be a close simulation of the target. I know that isn't
always true now, but that is the direction the UI sim has always been
>> 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 don't see any problem here. These complications won't touch the SDL
> app, because it will not define SIMULATOR.
I don't understand your answer. My suggestion is that the
LCD-simulating SDL code for the sim will be very different to the SDL
code needed for RaaA, so it shouldn't be assumed that unifying it is a
good idea - just because they are both using SDL.
>> Am I missing something obvious? Why is putting the sim code in target
>> tree a good idea?
> I think you mix up sim-specific code and sdl specific. The former will
> stay specific for the simulator, the latter will be reused for the sdl
> application because code duplication is bad.
Code duplication is not _always_ bad. My point with all this is that
you may want to do things in fundamentally different ways in an
SDL-based RaaA to the sim, and it's too early to say you won't.
>> 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
> That doesn't make sense to me. The difference between the sims and an
> SDL app boil down to the button and lcd handling. There need to be very
> few #ifdef SIMULATOR to separate the SDL app from the sim.
That may be the case now, but I would argue that it won't be the case
for very long.
I would have wanted to keep an open mind about the possibility that the
sim SDL code and RaaA SDL code would differ, and work on RaaA without
worrying about the sim.
If, much later during the development of RaaA, there is still a
significant amount of the sim's SDL code left in RaaA, then that would
be the time to consider merging the two, not now, before you've explored
Received on 2010-05-16