From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Sun, 28 Jun 2009 21:39:13 -0700

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.
At the bottom we have the button bar for those targets (this is currently
"broken" IIRC so needs to be fixed up.)
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).

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.

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.

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).

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
Received on 2009-06-29