|
Rockbox mail archiveSubject: Re: brain dump/plan re simplifying viewport/theme support in screensRe: brain dump/plan re simplifying viewport/theme support in screens
From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Tue, 1 Dec 2009 00:02:22 -0800 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 >>> >> >
Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |