Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: [RaaA] Weekly status report

Re: [RaaA] Weekly status report

From: Maurus Cuelenaere <mcuelenaere_at_gmail.com>
Date: Wed, 23 Jun 2010 13:59:29 +0200

Op 23-06-10 11:33, Jonathan Gordon schreef:
> On 23 June 2010 19:26, Maurus Cuelenaere <mcuelenaere_at_gmail.com> wrote:
>
>> Op 22-06-10 18:39, Thomas Martitz schreef:
>>
>>> Hi guys,
>>>
>>> again I'm busy due to uni stuff; I got a lot of practical and
>>> laboratory experiment courses lately. But slowly I'm getting
>>> somewhere. I'm currently preparing to commit the (first) RaaA target.
>>> It runs, but there's a few kludges which I want to sort out before.
>>> After that, I should work on having a proper "make install" mechanism,
>>> which implies (following last weeks discussion) to split up Rockbox'
>>> .rockbox folder into separate ones and to make some compile time
>>> constants runtime detectable.
>>>
>>> For a redistributable .zip (if we want that) we probably could stick
>>> to the single .rockbox approach, but for compiling from source and for
>>> distributions/windows installers we want something more application
>>> typical I think.
>>>
>>> I'm not sure what would be missing after that. I can't think of
>>> anything right now. If there's nothing I would start looking into
>>> Android. I today ordered the HTC Legend. Once the SDL app is
>>> considered finished, I guess you might have a different view of
>>> finished that me - we can discuss that, I can focus on the Android
>>> port. But I still need to dive into app development on Android before.
>>> That said, I'm completely unexperienced in that area, and I can just
>>> hope there aren't as many traps as I fear.
>>>
>> I was wondering, how do you plan to handle the different screen
>> dimensions at runtime? For some platforms this isn't needed (Maemo only
>> has N900), but for others this is a requirement (Android, WinCE,
>> iPhoneOS, ..).
>>
>> I haven't seen much discussion towards this (though I haven't been on
>> IRC for some time), but I do think this is an important point.
>>
>> The obvious solution to this is defining LCD_HEIGHT and LCD_WIDTH as
>> variables and not building plugins, but I'm not sure how flexible the
>> apps/ layer is w.r.t. to these changes.
>>
>>
> I dont see that working without alot of effort. It might be possible
> to do scaling in the LCD driver, or more likely a seperate build would
> be done for each screen size (Pretty sure android market lets you
> specify which lcd resolutions the app supports)
>

I hacked up this patch which replaces LCD_{WIDTH,HEIGHT} with variables.
I've only tested the Onda VX747 simulator without plugins, but
everything except WPS seems to be working.

And yes, you can specify what screen dimensions are supported in the
manifest packaged with your Android app AFAIK.

-- 
Maurus Cuelenaere

Received on 2010-06-23

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy