More closely matches native behavior on REAGL devices.
Closing those widgets should still trigger a partial refresh though,
because we usually get back to the reader, and text, so we want REAGL
;).
This is a larger clean-up of the refresh situation.
The general shift is that refreshes are now mainly triggered by
the (top-level) widgets when they get shown or closed via UIManager.
All refreshes for the widgets when they are in use were handled by
themselves before. This adds the case of showing/closing.
It is the desired result of not having UIManager:show()/:close()
do (full screen) refreshes on its own.
This serves as a good example for the way refreshes are done:
setDirty("all", function() ... end)
* the "all" will have all widgets on screen repainted.
In this case that is needed because the config pane has
different sizes, covering different parts of underlying
widgets. So they need to be repainted every time.
* the function will return the area to refresh and is evaluated
after painting. In this example, we take the area that is covered
by the config pane before switching it (if present at all), and
hand it to the refresh area function as an upvalue.
When the function is called later after painting, it will
use that saved area and combine it with the area that is covered
then by the widget. That way, parts that are covered no more are
included in the refresh area, too.
This is the remaining gruntwork of #1276. I believe that only leaves networkmgr.lua and filemanagersearch.lua, which will require a little more thought.
This is a major overhaul of the hardware abstraction layer.
A few notes:
General platform distinction happens in
frontend/device.lua
which will delegate everything else to
frontend/device/<platform_name>/device.lua
which should extend
frontend/device/generic/device.lua
Screen handling is implemented in
frontend/device/screen.lua
which includes the *functionality* to support device specifics.
Actually setting up the device specific functionality, however,
is done in the device specific setup code in the relevant
device.lua file.
The same goes for input handling.
colors were a mixture of 4bpp integers (0=white, 15=black) and
fractional blackness levels (0=white, 1.0=black) before. This is
now unified to use the color specification of the Blitbuffer API.
This should finish the work to make all globals to local variables.
That allows LuaJIT to properly compile things by interning the
references to the relevant parts (rather than looking up globals
all the time which stops a trace).
