flyspray is down and I'm ready for bed... this version builds without
warnings on bitmap lcd...

This patch (imo) simplifies the statusbar and viewportmanager API's.
magically fixes a bunch of the current statusbar redraw issues, and
removes some GUI events which would be better if they wern't
required... This also removes the notion of a inbuilt statusbar..
either its enabled or its not (top/bottom/custom all still work),
which means that some screens which used to force the bar cant do this
anymore... I think the only big "issues" here is recording screen
(semi skinnable, so maybe not such a issue) and early chargin/usb
screens which can be sorted out separately.

please test it out and let me know how it goes...
Jonathan

2009/11/30 Jonathan Gordon <jdgordy_at_gmail.com>:
> 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
>>>
>>
>