Slider Size and Progress Contrast #3599
Conversation
|
Hello, a gif / picture would be welcome to see this in context! Thank you! |
|
This seems useful. I like the fact that contrast value can be negative, essentially inverting looks of the slider. Making slider thinner allows easily achieving looks similar to that of windows sliders. 👍 However implementation has some issues. Default contrast value changes looks of widgets, creating two segments on either side of slider knob. This should not be the case and default value should be As i understand contrast var is used to communicate how much of slider is filled. Adjusted contrast looks rather bad if slider thickness is bigger than knob itself. One of the solutions could be to not allow filled portion to be higher than slider grab. However it would create a border of different color around the slider, so might not be a best idea. Also now we have two elements communicating slider value: filled portion of the slider and knob itself. With some tuning (namely slider thickness == grab height) it looks OK, and we can completely hide grab by tuning colors. So that is good. I think removal of @ocornut a gif substitute https://streamable.com/qwtba7 |
|
@rokups thanks for posting a video. I wanted to do a gif but hadn't gotten to it yet... (Developing on a Chromebook and hadn't found a gif capture tool that works in that context...) I'll work on this since there are a lot of different looks that can be achieved here...
Thanks. I'm developing several audio applications and need to be able to illustrate organ draw bars so it seemed logical to use the range of +/-1. At either extreme the slider background of one side is completely invisible which produces the iconic draw bar look.
I did this to highlight the pixel discrepancy immediately with the grab as you note next...
Yes. Since the grab is a few pixels smaller than the slider track at full width it can look a little wonky with a large grab size. I thought of changing the grab thickness to totally fix this issue but I haven't implemented that yet. (Maybe I also thought about creating a modifier for What do you think? Should I stop here or add those two more Style Vars? |
|
@ocornut been having trouble recording video/gif on my computer. But many screenshots above... |
|
Screenshots look very good! These two style vars add a lot of flexibility apparently. As for discrepancy with contrast != 0 and slider bigger than grab... Gradients behind knob would make it visually less jarring. Or we could accept the fact that contrast != 0 is only meant to be used with slider thickness <= grab height. By the way, sliders can also act as progress bars now. Thats nice! |
Thanks @rokups. It's mostly @ebachard's work. I just polished it a little.
As to gradients in the slider track... While gradients may look nice, @ocornut has historically opposed them in the main widget set. As to programmers doing stupid things setting unreasonable values... At some point, we have to expect users to have some design sense. I'm working on a an online style generator to help with that. But I don't have a firm release date any time soon.
Actually there is a |
|
Thank you for your work on this. I think we will adopt something similar to that and the PR is a good enough base of work so treat my comments below as thoughts but don't necessarily have to rework the PR.
TL;DR; need to sort through this idea and maybe it means adding a few extra vars and find the sweet spot there. Most of those variables being "very rarely changing variables" (aka more likely set once in style and never touched using PushStyleVar) it should be able to have a few more. I think it'd be a good evolution and we can aim to alter the default look to have smaller value for thcikness, which would come with the property that sliders would be instantly recognizable (and the counter property that reliance on that may appear like a minor regression of affordance when a program use a style like to current one, though that would be easy to discourage if we make sure the default is a change from current one). Similarly it might be nice if we can make Drag box instantly recognizable. |
0c1e5bd to
bb6a60b
Compare
8b83e0a to
d735066
Compare
b3b85d8 to
0755767
Compare
c817acb to
8d39063
Compare
|
Very nice PR. Is this still being worked on for inclusion in master branch? |
|
This is one of the patches that i have to apply on every imgui related project i do, any chance this gets added to master? |
|
https://gist.github.com/TheOnlyJoey/cd4f7bcc753377821e14826be01e1b82 To make it easier, here is more modern patch based on current master. |
This is basically a cleaned up and expanded version of #2305 since that PR seems to have been abandoned due to a weird branch deletion. I was able to use GitHub CLI to pull the code for that PR and continue working on it. I loved the way this looked in the screen captures of #2263 but sadly the PR never quite reached maturity.
I followed Omar's suggestions on those threads for the drawing calls and then kept on going a little further with the idea of contrast that was beginning to percolate in that discussion. In the process, I fixed most of the weird annoying ways to draw sliders. I also found a where the demo was missing the GrabActive color for the vertical slider example.
This now provides quite a range of possible slider looks without much additional code.
PR adds two new Style Vars:
I do no know of anything lingering on this. But I'm open to suggestions. I tried to make this as generic as possible.
Please consider for inclusion... Thanks! 😃