it uses non-blocking turbo I/O looper to process http request
so that multiple http request can be handled simultaneously and http request
won't block user input, and most importantly, in Lua's way.
This eliminates the API difference between the extra parameters of
UIManager:show() and setDirty(). They work the same now.
Note that this also eliminates the automatic refresh that took place
before when using show() without refresh options. It always refreshed
the full screen, which led to too big refresh regions all over the
place. Thus, refresh has now explicitly to be asked for, hopefully
encouraging to implement it in the widget that gets shown (and is
aware about the screen region it covers).
Also add an event that is triggered when a widget is closed:
CloseWidget. So a widget can implement "onCloseWidget()" to trigger
actions upon closing - most commonly, this is a refresh for the area
previously taken by the widget. That way, the widget's user does not
have to take measures to ensure that the area is refreshed later.
for now, we have show() automatically call setDirty() for the new
widget, as before. However, now show() takes two arguments for
refresh configuration that will get passed on to setDirty().
For compatibility, the default is here in show() to do a partial
refresh. So if you want no refresh triggered (via this show() call),
add a function that doesn't return anything.
See documentation in the code.
In short: There is now one single method, setDirty(), that triggers
repaints and/or refreshes.
All variables in UIManager are gone - at least from an external
perspective. Everything is done through setDirty().
This also allows for easier debugging, since all requests come
in via function calls.
Lots of the device-related distinction wandered into
base/ffi/framebuffer_<driver>. This eases the refresh logic in
UI manager, which basically only decides what kind of refresh
to trigger. The device specific configuration in the framebuffer
driver decides how to realize that whish.
screen.lua is gone, in its place is now the framebuffer driver.
The device abstraction decides what framebuffer driver to load.
Don't increase counter for regional updates
Also some workarounds for Kobos
Try to avoid update_regions_func poisoning
Reset it at the end of repaint() even if nothing was found dirty
Ensure regional updates are always PARTIAL, in
case we get a region attached to an automatically triggered refresh, not
marked force_partial [which, hey, shouldn't happen, but apparently does
sometimes ^^]
Since commit 12a76fee33, we had a potential
bug on the event mechanism:
It introduced (besides the checkTasks method itself) a second run of the
checkTasks() method. In the second run, however, scheduled events were
not taken into consideration in how long to wait for input events
afterwards.
So when the after the first run of checkTasks() there were new scheduled
tasks added to the task queue, they were not properly scheduled and
and depended on an already existing scheduled event or an input event
to trigger.
This might have led to unexpected order of execution (though the order
is not guaranteed by the task scheduling anyway!) or to events triggering
not at all until the next input event.
re #1119
AUTO appears to be doing the right thing...
(even if that baffles me, given the state of the Kernel sources,
unless they flip some switches at compile time
[NTX_WFM_MODE_OPTIMIZED_REAGL / NO_AUTO_REAGL_MODE] ...)
Anyway, that's what nickel does, so follow its lead ;).
Don't hijack forced partial updates (i.e., from UI elements) on always
FULL REAGL devices. It doesn't implode if we don't, and it makes for a
snappier UI.
WIP, untested, can probably simplified some more.
Good news is, it should be smarter, and thus provide a smoother user
experience :).
Relies on the relevant changes in base.
We wouldn't want those to become full updates ;).
Also apply an optionally different waveform mode for such partial,
regional updates (right now, only Kindle devices make use of this finer
grained control).
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.
ConfirmBox and InfoMessage are default to be modal.
Now returning to filamanager after highlighting a PDF page
the confirmbox asking users to save the document will not be hidden by
the filamanager window.
And it's tested on Kindle that #791 is already been solved probably by
out refacorting of MuPDF backend.
