[UX] creoptions: add more margin values#4691
Conversation
|
👍 |
|
Looks fine. (It will just be a bit strange for people who did customized the 3 first ones in default.persistent.lua - probably they increased them, possibly beyond the 4th and 5th). |
|
Nothing to do with this PR, just brainstorming (even for a possible personal hack): |
|
Hint hint; that's what flash_ui is for ;p.
…On Fri, Mar 1, 2019, 13:15 poire-z ***@***.***> wrote:
Nothing to do with this PR, just brainstorming (even for a possible
personal hack):
On my GloHD, a refresh on a previously solid black area makes the
underlying test grayer/thiner instead of black.
So, with these black progress bars like contrast and this new one, I
usually follow quiting the bottom menu with a small diagonal swipe to full
refresh.
I don't think it's worth doing a full refresh when quiting a bottom config
dialog that would include these black bars - might not be needed on other
devices.
Just wondering if there's a visual idea for such progress bar without the
big solid blacks - while still as readable as to what is selected. I can't
think of any :|
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4691 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAG1Zs6FwJiGZ2wEr-Q_FmFzITLJL7ilks5vSRnwgaJpZM4bY3f3>
.
|
|
Although I vaguely recall having removed the flashing from the bottom menu
to avoid bad interactions with the top menu ;).
Stuff is generally far better on newer devices though ;).
(reagl devices will flash less w/ flash_ui, while also suffering much less
from ghosting).
…On Fri, Mar 1, 2019, 13:17 NiLuJe ***@***.***> wrote:
Hint hint; that's what flash_ui is for ;p.
On Fri, Mar 1, 2019, 13:15 poire-z ***@***.***> wrote:
> Nothing to do with this PR, just brainstorming (even for a possible
> personal hack):
> On my GloHD, a refresh on a previously solid black area makes the
> underlying test grayer/thiner instead of black.
> So, with these black progress bars like contrast and this new one, I
> usually follow quiting the bottom menu with a small diagonal swipe to full
> refresh.
> I don't think it's worth doing a full refresh when quiting a bottom
> config dialog that would include these black bars - might not be needed on
> other devices.
> Just wondering if there's a visual idea for such progress bar without the
> big solid blacks - while still as readable as to what is selected. I can't
> think of any :|
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#4691 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAG1Zs6FwJiGZ2wEr-Q_FmFzITLJL7ilks5vSRnwgaJpZM4bY3f3>
> .
>
|
|
I don't think it'd suffer in usability from using the same gray as the toggle switches, if that's any better for ghosting without a flash. PS I'll fix the unit tests later. |
|
Well, solid gray areas auto-flash-ui themselves on my GloHD :) and I really don't like that either (I've converted some of our gray lines to black in my own patch - separators in the menu were flashing and that did bother me). |
I might be overlooking something (especially since I haven't looked at the code and am therefore unaware of its comments) but I'd say either so should black or neither should gray, depending on which behavior is best? |
|
No worry with our code. It's the (GloHD at least) hardware that does this auto-flash with grey (it's not a single transition: it goes from white to black, and they from black to grey - or something like that - no matter what we use in our code). |
| DCREREADER_CONFIG_MARGIN_SIZES_HUGE, | ||
| DCREREADER_CONFIG_MARGIN_SIZES_X_HUGE, | ||
| }, | ||
| name_text_hold_callback = optionsutil.showValuesMargins, |
There was a problem hiding this comment.
Whoops, this deletion is a mistake. :-)
Updated for koreader#4691 Also the assert.is_same() argument order was wrong. The first argument is expected, the second the real-life result. Otherwise the error message in case of failure is misleading.
It's actually far better in grey on my GloHD (because of the HW auto-flash, which leaves no ghosting at all): A bit too monotonous though :) In case one wantd to try it on some other devices: --- a/frontend/ui/widget/buttonprogresswidget.lua
+++ b/frontend/ui/widget/buttonprogresswidget.lua
@@ -43,13 +43,15 @@ function ButtonProgressWidget:update()
local button_margin = Size.margin.tiny
local button_padding = Size.padding.button
local button_bordersize = Size.border.button
- local preselect
+ local preselect, background
local button_width = math.floor(self.width / self.num_buttons) - 2*button_padding - 2*button_margin - 2*button_bordersize
for i = 1, self.num_buttons do
if self.position >= i then
preselect = true
+ background = Blitbuffer.COLOR_GREY
else
preselect = false
+ background = Blitbuffer.COLOR_WHITE
end
local button = Button:new{
text = "",
@@ -60,6 +62,7 @@ function ButtonProgressWidget:update()
enabled = true,
width = button_width,
preselect = preselect,
+ background = background,
text_font_face = self.font_face,
text_font_size = self.font_size,
callback = function()
Indeed, no flash on the bottom menu. |
|
Holding on margin title (to have help text) now crashes with: (No crash when holding on the Contrast title) |
Updated for koreader#4691 Also the assert.is_same() argument order was wrong. The first argument is expected, the second the real-life result. Otherwise the error message in case of failure is misleading.
Updated for koreader#4691 Also the assert.is_same() argument order was wrong. The first argument is expected, the second the real-life result. Otherwise the error message in case of failure is misleading.



Fixes #4684.