Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Widget ID == Label #647

Closed
josiahmanson opened this issue May 10, 2016 · 4 comments
Closed

Widget ID == Label #647

josiahmanson opened this issue May 10, 2016 · 4 comments
Labels
label/id and id stack implicit identifiers, pushid(), id stack

Comments

@josiahmanson
Copy link
Contributor

The widget ID seems to be the same thing as the label. Maybe I'm missing something, but this seems to mean that I can't use inputs without a label, because if I set all of the inputs to have the empty label string "", then they all get selected and interfere with each other. I'm getting around this by just deleting the code that displays a label within the widget.

Maybe the best solution is to add an optional ID field that will be used for the ID instead of the label when supplied? Maybe get rid of the label entirely like I did, and rely on the user calling SameLine();Text("label"); to get the label? Actually this second option sounds surprisingly reasonable to me, because they there is a possibility to put the label in front of the text also.

@ratchetfreak
Copy link

or use the ## to add a invisible label.

In other words have the label string be "##textInput"

https://github.com/ocornut/imgui/blob/master/imgui.cpp#L318

@josiahmanson
Copy link
Contributor Author

Thanks ratchetfreak. I would never have guessed that "##" and "###" substrings had some special meaning w.r.t. IDs. It is good to know this exists, but I still think it is bad API design to have the ID be hidden in the label string.

My suggestion of having a separate, optional, ID argument would make the ID more explicit in the API and more discoverable. It would be obvious how the function works by looking at its definition in the header instead of relying on an FAQ. If people are asking frequently, maybe it is confusing.

@ocornut
Copy link
Owner

ocornut commented May 11, 2016

It's all in the FAQ. Maybe the FAQ has to be prominent. There's also a concept of id stack.

You think it is bad api design I think it is a perfectly elegant and functional idea to do that. We're not going to add an extra parameter to EVERY function to cover an uncommon case.

You can instead mix up "##blah" and SameLine/Text stuff to combine elements. I'd advise against trying to aim for a label-on-the-left-widget-on-the-right layout style. There's a set if layout options in the work to allow it automatically on all widgets but it has many less benefits than the opposite in term of layout flexibility.

@ocornut ocornut closed this as completed May 11, 2016
@ocornut
Copy link
Owner

ocornut commented May 11, 2016

For the record I agree it would be more discoverable to have explicit two parameters, but an API is also about being practical and efficient. Trading discoverability for a forever heavier-api not always worth it.

Once you get how this works in ImGui then you are set.

Note however that eg this is exactly what the TreeNode API is doing, we have variants taking an ID + a format string to display that is independant from the ID. All those micro choices are also decided because of c++ constraints (eg: if c++ could allow the user to reasonably format string or pass slices to any functions then we wouldnt have format string parameters in the api. Alas c++ is pretty much a shitty language!)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
label/id and id stack implicit identifiers, pushid(), id stack
Projects
None yet
Development

No branches or pull requests

3 participants