Rockbox mail archiveSubject: Re: [RaaA] Move SDL stuff to target tree
Re: [RaaA] Move SDL stuff to target tree
From: Frank Gevaerts <frank_at_gevaerts.be>
Date: Sat, 8 May 2010 22:00:00 +0200
On Sat, May 08, 2010 at 03:41:49PM +0200, Thomas Martitz wrote:
> So, as part of my gsoc project I would like move uisimulator/sdl/*.[ch]
> to the target tree. Specifically into a directory
> firmware/target/hosted/, as hosted would probably also contain files for
> other hosts, such as android, and also (directly under hosted/) files
> which are not dependant on the host very much, such as my pth thread
> This is a large part of the groundwork for an application framework.
> It would look like this (in firmware/target/hosted):
> sdl/timer-sdl.c (the current uisimulator/sdl/timer.c)
> sdl/pcm-sdl. (the current uisimulator/sdl/sound.c)
> sdl/system-sdl.c (for initialization stuff)
> uisimulator/sdl/uisdl.c would be split up across the above files, for
> instance the initialization parts into system-sdl.c, the button parts to
> button-sdl.c etc.
> Additionally, part of sound.c goes as audio-sdl.c under
> firmware/drivers/audio/. Along with this work some SIMULATOR #ifdefs
> would be resovled as the simulator would behave more like a real target.
> BTW, the simulators would/should still work as before, with the
> exception that they're build using the SDL target.
> The above would be the first step. In a further step, I would like to
> split up button-sdl.c so that the simulator parts (particularly the
> keyboard-button maps for the simulated targets) into a plain button
> driver and into the simulator part into
> uisimulator/<target-name>/button.c. The UI-*.bmp files would also be in
> that folder.
> This is what I thought about so far. The groundwork wouldn't be finished
> with that but it's a pretty big step.
> 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 good to me
> Best regards.
-- "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. KernighanReceived on 2010-05-08