dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: "Design" notes for the (hopefully) upcoming viewport/screen changes

Re: "Design" notes for the (hopefully) upcoming viewport/screen changes

From: Thomas Martitz <>
Date: Tue, 30 Jun 2009 00:49:44 +0200

Jonathan Gordon wrote:
> In an attempt to get everyone on the same page regarding viewports,
> the statusbar, (background wps), and UI screens in general.. I thought
> I better write some stuff down...
> Obviously, everything in this is up for debate, although I don't think
> there is any objections so.... (And this is generally all going to
> happen post FS#8799 being commited)
> Each physical screen will be split into 2 (or 3/4) parts....
> below is my horrible acsii-art view of how it will be logically split.
> (monospace face required :p )
> +------------------+
> | statusbar |
> +------------------+
> | /---------\ |
> | * | UI AREA | |
> | | | |
> | \_________/ |
> +------------------+
> | button bar |
> +------------------+
> At the top of the screen is the usual 8px high statusbar (if it is
> enabled of course), we could potentially allow this to be moved to the
> bottom of the screen but I don't think thats really necessary.

I'd like to have this feature.
> At the bottom we have the button bar for those targets (this is
> currently "broken" IIRC so needs to be fixed up.)

I've never seen it in action anyway. Do we really need it, I remember
you said there's only 1 target that has it anyway? (to answer your next
email too a bit). In my impression, it makes coding just a pita.
> The middle area is going to be split by the users config. That "UI
> AREA" is where all screens MUST draw in (with the exception of the
> splash (MAYBE)), This part could take up the entire screen if the bars
> are disabled... The important thing here is that UI screens work in
> that viewport and don't assume they own the whole screen.
> The area outside of that "UI AREA" is going to be special... What I'd
> really like is to allow that to either be dead space (so just showing
> the backdrop from the menu), or have it displaying part of the WPS
> (requires the themer to do extra work here, but proof of concept works
> well).

That's how my customlist patch is designed so far. Splashes are really
problematic. And there're a few places (mostly: debug menu) where UI
doesn't count but a maximum of displayed information

If it's all done properly, we don't need to care about the outside area.
My patch has a mechanism to clear it anyway in case of the WPS for
example (we don't really want to restrict it to the UI area, do we?).
> How this all needs to work is with the viewport_manager_*() functions
> (badly named, someone come up with something better?.) When a screen
> wants to do some drawing they need to call
> viewport_manager_get_uiarea() which will return a viewport which you
> can draw in... 0,0 in this viewport could literally be anywhere on the
> display so screens need to be able to handle not owning the full thing.

That get_viewport function is also already implemeted in my patch. It
was needed to avoid giving simple things like set_int() or the
simplelist (though, the simplelist doesn't call it yet), a way to draw
in the active, not necessarily UI area viewport without poluting the
parameter list further.
It's a handy function after all.
> The buttonbar is a bit wierd because its linked to individual screens,
> but it outside the usual ui area... so quick aside here is to remove
> it completly..... (or not....)
> There is going to be some cases where the full screen needs to be
> stolen (the quickscreen is an obvious example), so there will need to
> be a viewport function which will disable the background wps drawing
> (if enabled), the buttonbar and the statusbar (if enabled, but also
> this one will probblay be optional.) If a screen calls this, it MUST
> reenable everything when it exits.

I don't think the quickscreen needs to be fullscreen. It can be
perfectly fine within the UI area.
> Plugins are special cases and I tihnk the plugin loader should be
> responsible of disableing everything when a plugin loads and
> reenableing everything on exit. The menu widget will probably be made
> to always enable the statusbar (if its enabled by the user) and the
> buttonbar (ditto). This will give a nice consistant look to everything
> using the standard menu (which all plugins do now).

I'm still unsure about the disable thing, especially for the statusbar.
I think plugins should handle setting up there own drawing boxes, but it
will be much work, indeed.
On the other hand, it would be nice if a do_menu call would look like in
the core without the plugin doing anything. Is there a simple solution?
Plugins will need to switch between UI area and fullscreen much more often.

Currently, you can deactivate the UI viewport using
viewportmanager_set_ui_vp(false), but everything that uses the NULL
viewport still gets the UI viewport.
> The last thing is the background WPS idea. The way my proof-of-concept
> worked was with a flag in global_status which was set to true if the
> WPS is being drawn in the actual WPS screen, or 0 if it was in the
> menu. Themers need to be careful here and use that conditional to make
> sure to not draw in the rectangle where the "UI area" is (or the
> statusbar of course). It would get updated like how the statusbar is
> now... so in every action_get() call (pretty much once per redraw of
> every screen, so screens which loop on HZ/x will look better than
> those which block). If this is enabled there will most probably be a
> battery hit, but thats up to the user if they want it or not (and it
> does look nice... :) )
> so... comments, questions, suggestions?
> Jonathan
That would definitely be neat. But the wps needs more updating, let it
be alone progress bar. There could also be the case where you want the
peakmeters in the mainmenu, which need constant updating.

I think we could have the WPS define areas to be shown, e.g. special
viewports, or rather updated, while being in other screens. The wps
update routines would only update these areas then.

Nevertheless, I'd absolutely love that feature.
Received on 2009-06-30

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