Rockbox mail archive
Subject: Re: brain dump/plan re simplifying viewport/theme support in screens
Re: brain dump/plan re simplifying viewport/theme support in screens
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...
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
>> 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...)
>> 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
>>> anyway.. have a open mind over this... we can argue in the morning :)
Received on 2009-12-01
Page was last modified "Jan 10 2012" The Rockbox Crew