* 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
-- 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.
-- NOTE: Except when a Button is flagged vsync, in which case we *want* to bundle the highlight with the callback, to prevent further delays
ifnotself.vsyncthen
UIManager:forceRePaint()
-- 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 ;).
-- 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,
-- Remember that the whole eInk refresh dance is completely asynchronous: we *request* a refresh from the kernel,
-- causing mild variants of our friend the papercut refresh glitch ;).
-- but it's up to the EPDC to schedule that however it sees fit...
-- Remember that the whole eInk refresh dance is completely asynchronous: we *request* a refresh from the kernel,
-- The other approach would be to *ask* the EPDC to block until it's *completely* done,
-- but it's up to the EPDC to schedule that however it sees fit...
-- but that's too much (because we only care about it being done *reading* the fb),
-- The other approach would be to *ask* the EPDC to block until it's *completely* done,
-- and that could take upwards of 300ms, which is also way too much ;).
-- but that's too much (because we only care about it being done *reading* the fb),
UIManager:yieldToEPDC()
-- and that could take upwards of 300ms, which is also way too much ;).
end
UIManager:yieldToEPDC()
end
-- Unhighlight
--
-- 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'll *paint* the unhighlight now, because at this point we can still be sure that our widget exists,
-- 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.
-- and that anything we do will not impact whatever the callback does (i.e., that we draw *below* whatever the callback might show).
-- Worst case scenario, we'll simply have "wasted" a tiny subwidget repaint if the callback closed us,
-- 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.
-- 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,
-- Worst case scenario, we'll simply have "wasted" a tiny subwidget repaint if the callback closed us,
-- which would require a number of possibly brittle heuristics to handle.
-- 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,
-- 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.
-- which would require a number of possibly brittle heuristics to handle.
ifnotself.vsyncthen
-- 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
UIManager:forceRePaint()-- Ensures whatever the callback wanted to paint will be shown *now*...
-- 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).
ifself.vsyncthen
UIManager:waitForVSync()-- ...and that the EPDC will not wait to coalesce it with the *next* update,
-- 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).
-- because that would have a chance to noticeably delay it until the unhighlight.
UIManager:waitForVSync()-- ...and that the EPDC will not wait to coalesce it with the *next* update,
end
-- because that would have a chance to noticeably delay it until the unhighlight.
end
-- Unhighlight
--
-- 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.
-- 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,
ifself.vsyncthen
-- so we can do this safely without risking UI glitches.
NiLuJe
3 years ago
committed by
GitHub