From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Mon, 30 Nov 2009 22:12:36 -0800

small update.. closer to being reviewable.... WPS doesnt work as
expected, rec screen and lists do, plugins almost working...

2009/11/25 Jonathan Gordon <jdgordy_at_gmail.com>:
> more brain dump...
> end of last week it was agreed on that really the only place where
> having a "statusbar" is absolutly required is *early* usb and charging
> (early being almost never seen by users because its handled in the
> bootloader...)
> So, the better solution than trying to hardcode a fallback sbs (like
> the fallback wps) is to fix those screens with some pretty
> aniumations, or actually lay the info out on the screen better (TBD).
>
> What this means (along with the api rework) is that the only screens
> that would ever need to enable/disable the theme are ones which
> actually only disable the theme, all others would just assume that the
> theme is active. This means a fair bit of simplification (specifically
> the fm and rec screens).
>
> We could allow some screens to force toggle the theme (e.g do_menu() )
> but I'm leaning more to making it required of the calling code to
> re-enable the theme before calling do_menu() which means we can get
> rid of some logic there which currently handles showing the bars.
>
> The big annoyance will be for plugins here.. so we could fix a
> do_menu() wrapper for them to undo the theme, call do_menu(), then
> redo the theme change... not sure if thats a good idea though.
> In the core, I cant think of too many screens which would ever need to
> disable the theme... (Actually, only the quick/pitch screens, and the
> graphic EQ changer screen come to mind...)
>
> Jonathan
>
> 2009/11/24 Jonathan Gordon <jdgordy_at_gmail.com>:
>> Attached is my very quick first effort of doing this change in svn...
>> it doesnt work, and doesnt even compile yet.. yet enough has changed
>> so you get some idea of how it simplifies the API a bit (not much
>> though, but some...)
>>
>> It turns out that we probably cant completely hide _Set_fullscreen and
>> set_default to just viewport.c, although I'd really like to....
>> The reason why one funciton for both (externally) works is because of this:
>> 1) A screen knows how much room it needs... it has exactly 2 choices,
>> a) use the theme, or b) use full screen.
>> 2) with a single API call it can say "disable the theme, and setup the
>> viewport for full screen" which does everything else needed in the
>> background (i.e disabling the sbs updateing, etc)
>> 3) if a screen calls _set_fullscreen without disabling the sbs then
>> bad things will happen, doing it in 1 api call eliminates that
>> problem.
>>
>> anyway.. have a open mind over this... we can argue in the morning :)
>>
>> Jonathan
>>
>

Received on 2009-12-01