Suggestion, about theme colors ...

[moebiussurfing]

Hey,
I tried some themes to see how the colors pair with other widgets, etc...
I think that the "knob" color, it “collides”, especially with the slider grabber.
Maybe it could be cool to have the same color as the slider.
What do you think?
Regards

[nitz]

Yeah I see what you're saying. That's partially why I had hard coded the gray colors in the first go at it. I think it mostly works as the slider grabber color, but gets lost a little bit depending on frame bg and frame bg hovered.

In particular, like the one you've got here:

it seems to wash out a bit. (It's not horrid, but certainly does make more sense than ImGuiCol_Text)

Excuse my poor mspaint rendition:

Actually I wonder if ImGuiCol_CheckMark makes more logical sense — looks like it's mostly the same as the slider grabber in most of the themes I have, but perhaps semantically fits a bit better. I'm hoping when "styling 2.0" comes around extendable named colors or the sort will be part of it for cases just like this.

[moebiussurfing]

PS:
Thanks a lot for checking my "whims". And sorry for abusing your trust. ;)

Another little idea is to treat that rounded toggles as the core buttons or sliders,
in terms of allowing change their dimensions.
The width and height of the widget maybe has no relevance on a checkbox, aka the default core toggle.
(All are good being small, always the same size.)
But on sliders, buttons and that rounded toggles, maybe could be useful to customize the shape size (adding an ImVec2 bb arg ...)

Personally, that's how I am using my custom rounded toggle, and also another rectangle toggle that I have, based on the core button with custom size too.

Regards!

[nitz]

For design/styles:

I definitely modeled my default design after @ocornut's and also the default iOS style one. I think at a minimum of what I may want to do (at least until styling v2) is perhaps a set of flags that just imply a set of nice "pre-canned" styles for someone to use out of the box. I also was noodling around on my iPad this weekend and realized I have the accessibility option turned on that shows the "I" or "O" on the frame to indicate the state of the switch for those that have a hard time seeing color, I think I'm going to add that as well.

Now on to sizes

I definitely like the look of your multi-size toggles as well. (Particularly those larger ones look fantastic in your theme colors too.) I'm a bit afraid of the parameter list getting a little noisy to continue adding optional things like size, but I don't see anything in ImGuiStyleVar_ that would make sense as an alternative way to specifying the bounding box, so maybe it's the only "real" option. Do you want to take a look before I jump in and add that?

I'm realizing now that there's a whole slew of things that I'd love to be easily user-controllable (that I suppose could be w/ styling v2): bounding box w/h, knob w/h, knob inset, border thickness, etc.

[moebiussurfing]

I'm a bit afraid of the parameter list getting a little noisy to continue adding optional things like size, but I don't see anything in ImGuiStyleVar_ that would make sense as an alternative way to specifying the bounding box, so maybe it's the only "real" option. Do you want to take a look before I jump in and add that?

I'm realizing now that there's a whole slew of things that I'd love to be easily user-controllable (that I suppose could be w/ styling v2): bounding box w/h, knob w/h, knob inset, border thickness, etc.

I am not an expert at all on ImGui, just learning here.
I just made some helpers with small tweaks but I didn't make before a "complex" widget by myself.
I am unsure if I understand all the points,
or if I am unaware of some implications of adding more "noise to the API".
BTW thanks for listening to my whims.

In the case of the regular square buttons (and custom toggles) I usually use:

float w = ImGui::GetContentRegionAvail().x;
float h = ImGui::GetFrameHeight();
ImGui::Button("DoubleH", ImVec2(w, 2 * h));

Having this ImVec2 sz on my widgets,
I am usually able of doing responsive layout like that:

/*
      RESPONSIVE LAYOUT
      2 DOUBLE HEIGHT BUTTONS IN ONE LINE +
      3 SINGLE HEIGHT BUTTONS IN ONE LINE
      WITH DIFFERENT PROPORTIONS
*/
      float w = ImGui::GetContentRegionAvail().x;
      float h = ImGui::GetFrameHeight(); // single unit height
      float hh = 2 * h; // double height
      float spx = ImGui::GetStyle().ItemSpacing.x; // spacing between two widgets
      float _spx; 
      // Calculate spacing for each line:
      // _spx = (spx * (amount - 1)) / amount;  // amount widgets per line
      _spx = (spx * (2 - 1)) / 2;
      ImGui::Button("B1", ImVec2(w * 0.25 - _spx, hh));
      ImGui::SameLine();
      ImGui::Button("B2", ImVec2(w * 0.75 - _spx, hh));
      _spx = (spx * (3 - 1)) / 3;
      ImGui::Button("B3", ImVec2(w * 1 / 3.f - _spx, h));
      ImGui::SameLine();
      ImGui::Button("B4", ImVec2(w * 1 / 3.f - _spx, h));
      ImGui::SameLine();
      ImGui::Button("B5", ImVec2(w * 1 / 3.f - _spx, h));

So, in the case of my own rounded toggle widgets,
I added an argument ImVec2 sz = ImVec2(-1,-1).
When nothing is passed, it draws the default size.
In the case of your rounded toggle, you can pass only one of args w or h, passing FLT_MIN/FLT_MAX,
but I don't understand 100% how they work.

In the case of these rounded toggles, usually,
you could pass the height only, and apply internally the proportional ratio for the width. (to not deform too much.
EDIT: or maybe a simpler 'float scale = 1.0f' as single unit line height. Then scale = 0.7, 1.0, 1.5, 2.5 it could be passed.

Or maybe could use a flag or enum (more noisier maybe) as MINI, DEFAULT, BIG, HUGE.
Then using internally H = GetFrameHeight() as a unit: 0.7 * H, 1.0 * H, 1.5 * H, 2.5 * H

The simplest way to be used without any argument,
I think could be something like that:

float w = ImGui::GetContentRegionAvail().x; // this is the full window width
ImGui::PushItemWidth(w);
ImGui::SliderFloat("##1", &v, 0, 1); // full width without label
//ImGui::Button("Button"); // not reacting
ImGui::PopItemWidth();

But in the case of the above button, it does no reacts to that width push.
Maybe PushItemWidth applies only to some widget types.
Also, there's no ImGui::PushItemHeight on the API...
So in your case, a workaround could be something like

float sz= 2.0f; // double H
ImGui::PushItemWidth(w); 
// then internally react to the width style 
// but by using it into the height + proportionally to the width.
ImGui::Toggle("Default Toggle", &toggle_a);
ImGui::PopItemWidth();

But is too dirty bc the toggle size is more related to the theme height, not dependent on the current window width.
So, I think that ImGuiStyleVar_ is more related to the theme than to the layout... (?)

You could pick some ideas from here perhaps:
https://github.com/altschuler/imgui-knobs
On these knob widgets, you can see that some flags can be "queued as multi choice" like your ImGuiToggleFlags_.
Here it passes a single float size = 0 to customize the size.
BTW on this widget is more important to unlock size customization.

static float value = 0;
ImGuiKnobFlags flags = ImGuiKnobFlags_ValueTooltip | ImGuiKnobFlags_NoTitle | ImGuiKnobFlags_NoInput;
ImGuiKnobs::Knob("Value", &value, -6.0f, 6.0f, 12 / 250.f, "%.1fdB", ImGuiKnobVariant_WiperDot, 100, flags);

Sorry for the long message. A little thinking out loud...
Of course, forget about it if you feel it is messy, or preferring to wait Styling v2.
Surely is enough to have an alternative to the checkbox as it is, and it's very cool.

[nitz]

Sorry for the long message. A little thinking out loud...

Not at all, I really appreciate the detailed thoughts!

In the case of your rounded toggle, you can pass only one of args w or h, passing FLT_MIN/FLT_MAX,
but I don't understand 100% how they work.

This is more of a carryover from the original discussion. (Not sure where the decision to use width = height x 1.55, but it worked nicely with knobs that are width = height visually. However, especially with your responsive layout examples, I do quite like the idea of it being customizable.

I definitely agree that ImGui::PushItemWidth(w); feels like it would get way noisier than it should. It makes me feel a bit like it's running into a bit of parameter fatigue a-la the win32 API. Perhaps an overload that takes a POD struct to describe all desired settings & functionality existing along side the "quicker" APIs. Would give you the flexibility to specify all sorts of things, plus the ability to re-use chunks of settings too.

I'll thumb something out when I get a bit of free time and see what you think.

[nitz]

Hey, when you get a bit to play with it, try checking out this branch and let me know what you think: https://github.com/cmdwtf/imgui_toggle/tree/feature-customization

Here's a quick gif:

[moebiussurfing]

Good job. It looks like if they were from the NASA ;-).
Super customizable.

Definitely i'll migrate my legacy rounded toggles to that ones you made.

Also your code style is so clean, and looks well done. Good to learn from.
Could be inspiring to me also to make or improve other widgets.
i.e. I am planing to boost that range slider a bit:

About small things that surely you seen too:

• name label hover reacts the same that he knob.
• label text is no y centered when toggle is bigger.
• not sure if left window border padding is being applied. my toggles have more spacing... But not sure bc slider looks well aligned.

[nitz]

Also your code style is so clean, and looks well done. Good to learn from.
Could be inspiring to me also to make or improve other widgets.

I really appreciate that! I fret a lot about my C++ style, mostly because I can't decide what I want a lot of my style to be (compared to say C# where I mostly just follow Microsoft's style haha.) I'm quite glad you find it readable!

i.e. I am planing to boost that range slider a bit:

Woah those look excellent, are they in ofxSurfingImGui? I was just thinking that I was probably going to need a range slider along those lines. I use the "range" sliders often in Unity, and realized I wanted something similar for DearImGui:

name label hover reacts the same that he knob.

This was actually intentional. I mimic'd the behavior of the checkbox, which treats it's label as part of it's interactable area too.

label text is no y centered when toggle is bigger.

I've got that one fixed locally, just not super thrilled with how I've done it at the moment so I'll have it cleaned up when I merge it into main.

not sure if left window border padding is being applied. my toggles have more spacing... But not sure bc slider looks well aligned.

I'll look into this. Tweaking all of this made me realize I was handling border/padding wrong in a lot of my helper code I've got in a project, so there's a good chance I'm missing something. Please do shout if you notice specifically what it may be!

[moebiussurfing]

Looks cool.
That feature of "drag from center" is super useful.

This is the range slider from the above pic:
https://github.com/moebiussurfing/ofxSurfingImGui/blob/e212727dca18362871c6aca4b3e9bfebdeece178/src/ImGui/widgets/SlidersRange.h#L261

I think that this range slider came from here:
ocornut/imgui#76
or here
wasikuss/imgui@a50515a

Here is another one but too simple:
https://github.com/iamclint/ImGuiRangeSlider

[nitz]

Fantastic! I really appreciate the links!

Also: I just pushed a handful of commits and merged to main, I added a handful of more things:

• Added a color palette option. (Still falls back to theme colors, but I found myself wanting to override individual toggles without using lots of push/pops.
• Added an offset for the knob (so it can be offcenter or even out of the frame, see the "Material Style" one)
• Added (optionally) interpolating knob colors while animating similar to the frame color. (Ditched the 'Highlight' option for it, since this was more flexible.)
• Added the size parameter to the shortcut APIs, since I figured that'd be one of the most common things.
• Fixed the label being centered (as well as the a11y labels.)
• Changed the animation "speed" from a bit of a convoluted multiplier to instead just be desired animation duration in seconds.

Let me know if you run into any issues or bugs. And as usual, here's a gif: