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



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

From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Wed, 25 Nov 2009 22:54:38 -0800

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-11-26

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