SetItemKeyOwner missing

[gregsn]

Hi!

I'd like to stop a window from scrolling when using the mouse wheel over a certain item.
This should be doable with SetItemKeyOwner(ImGuiKey_MouseWheelY);

The function however is marked as internal:
"location": "imgui_internal:3519",

I guess there is a technical reason for making it internal.
Would be awesome, however, if there would be a way to make it public...!

[zaafar]

You have to ask imgui folks (https://github.com/ocornut/imgui) to make it public.
imgui.net doesn't have any control over it without exposing all internal functions.

Advance Warning: They have a process for making the API public (ref: ocornut/imgui#4207 (comment)) so it's really a waiting game and praying they ppl use this feature in C version of the lib. :)

[gregsn]

Oh wow!
You asked for that same function in 2022...

To me, it sounds like, when using the original library you have access to those functions. So calling them "internal" doesn't sound like the right term here. Rather they are an "experimental" / "preview" part of the library ... but all of those functions are publicly accessible.

So when @ocornut writes "I think you should ask for your C# bindings to allow access to imgui_internal too." it sounds like he suggests that similarly to the original library, all of it should be usable, maybe flagged with an experimental attribute(?)

What do you think?
Waiting for the authors of the Imgui library to fix the issue sounds off somehow.

[zaafar]

Yeah experimental does sound better but then all experiments should end someday. I don’t think that’s the case for some of those functions so I guess internal is better. :)

About exposing all internal functions in imgui net, it was decided before I joined this community. I guess their concern was that those functions changes a lot so it would be painful for end user of this lib to upgrade imgui.net. I personally haven’t tested that so I don’t know.

[ocornut]

Some of imgui_internal.h are expected to eventually transition into public api, and designed as such, while some of imgui_internal.h are really not meant to be used. This function is the earlier.

I believe it would make sense that selected functions from internal.h may be exposed into other languages, marked as experimental.

[ocornut]

I've been reluctant to move those API to public because I am not happy with the fact that they are obtuse, and it's easy to get things wrong. I particularly worry that some large applications through sloppiness and copy and paste may become a parade of incorrect-or-unnecessary code altering and testing key ownership everywhere.

But in principle I don't think those API will change much. SetItemKeyOwner() in particular being one of the higher-level construct and the only one that doesn't require an explicit owner ID, may be the easiest to move in public realm.

[ocornut]

I don't know how ImGuiNET is built, but I personally believe it would be great if as a precedent some imgui_internal.h function would be manually imported and made available. Mostly to set a precedent that "it is possible" and to also in term of documentation to facilitate the possibility that users may be empowered to occasionally add their own.

(as a tangential comment: I would love if ImGuiNET wanted to consider switching to https://github.com/dearimgui/dear_bindings instead of cimgui and I believe it may be a major push for the later as well. Dear Bindings gives you extra metadata where in theory you could generate bindings with full commentaries. One of the reasons I wanted Dear Bindings to exists is that cimgui puts all imgui_internal.h stuff in the same file with no distinction... which I found very bad and its maintainer never wanted to address that. But the irony is that Dear Bindings doesn't currently parse/output imgui_internal.h well, but I suspect it's achievable with a little bit of work, we need some hero to help push/finish dearimgui/dear_bindings#47)

[ocornut]

Added SetItemKeyOwner(ImGuiKey key) in public API:
ocornut/imgui@f9cda1f

For various reasons I am not yet confident to expose the flags. Because exposing e.g. locking concepts would require exposing the whole suite of functions. And I am not sure the ImGuiInputFlags_CondHovered and ImGuiInputFlags_CondActive flags specific to SetItemKeyOwner() are very valuable, they are merely a minor optimization.

[zaafar]

I don't know how ImGuiNET is built, but I personally believe it would be great if as a precedent some imgui_internal.h function would be manually imported and made available. Mostly to set a precedent that "it is possible" and to also in term of documentation to facilitate the possibility that users may be empowered to occasionally add their own.

i like this idea, will see how this can be achieved.