|
Rockbox mail archiveSubject: Re: [RaaA] Move SDL stuff to target treeRe: [RaaA] Move SDL stuff to target tree
From: Thomas Martitz <thomas.martitz_at_student.htw-berlin.de>
Date: Sun, 16 May 2010 15:41:34 +0200 Am 16.05.2010 15:23, schrieb Dave Chapman: > 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 >> discussion. >> >> >> 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 > code. No, I don't think RaaA aims to use less and less Rockbox code. It's a port of Rockbox afterall. > > 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). > > 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 > insertion/removal. 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. We want to run code which compiles for a target on a more convinient system (simulate), not emulate the target itself. > > 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. > > > 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. > > 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 > direction). > > 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. Best regards. Received on 2010-05-16 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |