* Menu/KeyValuePage/ReaderGoTo: Unify the dialogs. (Generally, "Enter page number" as title, and "Go to page" as OK button).
* Allow *tapping* on pagination buttons, too. Added spacers around the text to accommodate for that.
* Disable input handlers when <= 1 pages, while still printing the label in black.
* Always display both the label and the chevrons, even on single page content. (Menu being an exception, because it can handle showing no content at all, in which case we hide the chevrons).
* KVP: Tweak the pagination buttons layout in order to have consistent centering, regardless of whether the return arrow is enabled or not. (Also, match Menu's layout, more or less).
* Menu: Minor layout tweaks to follow the KVP tweaks above. Fixes, among possibly other things, buttons in (non-FM) "List" menus overlapping the final entry (e.g., OPDS), and popout menus with a border being misaligned (e.g., Calibre, Find a file).
* CalendarView: Minor layout tweaks to follow the KVP tweaks. Ensures the pagination buttons are laid out in the same way as everywhere else (they used to be a wee bit higher).
-- Force the refresh by draining the refresh queue *now*, so we have a chance to see the highlight on its own, before whatever the callback will do.
ifnotself.vsyncthen
-- NOTE: Except when a Button is flagged vsync, in which case we *want* to bundle the highlight with the callback, to prevent further delays
UIManager:forceRePaint()
-- NOTE: Yield to the kernel for a tiny slice of time, otherwise, writing to the same fb region as the refresh we've just requested may be race-y,
-- causing mild variants of our friend the papercut refresh glitch ;).
-- Remember that the whole eInk refresh dance is completely asynchronous: we *request* a refresh from the kernel,
-- but it's up to the EPDC to schedule that however it sees fit...
-- The other approach would be to *ask* the EPDC to block until it's *completely* done,
-- but that's too much (because we only care about it being done *reading* the fb),
-- and that could take upwards of 300ms, which is also way too much ;).
UIManager:yieldToEPDC()
end
-- Unhighlight
--
-- We'll *paint* the unhighlight now, because at this point we can still be sure that our widget exists,
-- and that anything we do will not impact whatever the callback does (i.e., that we draw *below* whatever the callback might show).
-- We won't *fence* the refresh (i.e., it's queued, but we don't actually drain the queue yet), though, to ensure that we do not delay the callback, and that the unhighlight essentially blends into whatever the callback does.
-- Worst case scenario, we'll simply have "wasted" a tiny subwidget repaint if the callback closed us,
-- but doing it this way allows us to avoid a large array of potential interactions with whatever the callback may paint/refresh if we were to handle the unhighlight post-callback,
-- which would require a number of possibly brittle heuristics to handle.
-- NOTE: If a Button is marked vsync, we want to keep it highlighted for now (in order for said highlight to be visible during the callback refresh), we'll remove the highlight post-callback.
UIManager:forceRePaint()-- Ensures whatever the callback wanted to paint will be shown *now*...
ifself.vsyncthen
-- NOTE: This is mainly useful when the callback caused a REAGL update that we do not explicitly fence via MXCFB_WAIT_FOR_UPDATE_COMPLETE already, (i.e., Kobo Mk. 7).
UIManager:waitForVSync()-- ...and that the EPDC will not wait to coalesce it with the *next* update,
-- because that would have a chance to noticeably delay it until the unhighlight.
end
-- Unhighlight
--
-- NOTE: If a Button is marked vsync, we have a guarantee from the programmer that the widget it belongs to is still alive and top-level post-callback,
-- so we can do this safely without risking UI glitches.
ifself.vsyncthen
self:_undoFeedbackHighlight(is_translucent)
UIManager:forceRePaint()
ifself.enabledorself.allow_tap_when_disabledthen
ifself.callbackthen
ifG_reader_settings:isFalse("flash_ui")then
self.callback()
else
-- NOTE: We have a few tricks up our sleeve in case our parent is inside a translucent MovableContainer...
-- Force the refresh by draining the refresh queue *now*, so we have a chance to see the highlight on its own, before whatever the callback will do.
ifnotself.vsyncthen
-- NOTE: Except when a Button is flagged vsync, in which case we *want* to bundle the highlight with the callback, to prevent further delays
UIManager:forceRePaint()
-- NOTE: Yield to the kernel for a tiny slice of time, otherwise, writing to the same fb region as the refresh we've just requested may be race-y,
-- causing mild variants of our friend the papercut refresh glitch ;).
-- Remember that the whole eInk refresh dance is completely asynchronous: we *request* a refresh from the kernel,
-- but it's up to the EPDC to schedule that however it sees fit...
-- The other approach would be to *ask* the EPDC to block until it's *completely* done,
-- but that's too much (because we only care about it being done *reading* the fb),
-- and that could take upwards of 300ms, which is also way too much ;).
UIManager:yieldToEPDC()
end
-- Unhighlight
--
-- We'll *paint* the unhighlight now, because at this point we can still be sure that our widget exists,
-- and that anything we do will not impact whatever the callback does (i.e., that we draw *below* whatever the callback might show).
-- We won't *fence* the refresh (i.e., it's queued, but we don't actually drain the queue yet), though, to ensure that we do not delay the callback, and that the unhighlight essentially blends into whatever the callback does.
-- Worst case scenario, we'll simply have "wasted" a tiny subwidget repaint if the callback closed us,
-- but doing it this way allows us to avoid a large array of potential interactions with whatever the callback may paint/refresh if we were to handle the unhighlight post-callback,
-- which would require a number of possibly brittle heuristics to handle.
-- NOTE: If a Button is marked vsync, we want to keep it highlighted for now (in order for said highlight to be visible during the callback refresh), we'll remove the highlight post-callback.
UIManager:forceRePaint()-- Ensures whatever the callback wanted to paint will be shown *now*...
ifself.vsyncthen
-- NOTE: This is mainly useful when the callback caused a REAGL update that we do not explicitly fence via MXCFB_WAIT_FOR_UPDATE_COMPLETE already, (i.e., Kobo Mk. 7).
UIManager:waitForVSync()-- ...and that the EPDC will not wait to coalesce it with the *next* update,
-- because that would have a chance to noticeably delay it until the unhighlight.
end
-- Unhighlight
--
-- NOTE: If a Button is marked vsync, we have a guarantee from the programmer that the widget it belongs to is still alive and top-level post-callback,
-- so we can do this safely without risking UI glitches.
NiLuJe
3 years ago
committed by
GitHub