map imgui_internal.h, integrations #7
Labels
faq
A frequent issue, remaining opened to facilitate discoverability
Comments
|
It's nice that you found this repository, since I did not communicate about it yet :-) I think you are the first one to discover it.
Yes, keeping the code layout and its doc was a main feature. I will communicate about the autogenerator in a few weeks.
I will have a look at it a bit later.
Actually, I do provide a backend via HelloImGui a library that I wrote. If you have time, could you try that and tell me if it works on your side?
Yes, it is part of the intent ! Note:
bool SliderInt(char* label, int *value)Either I "Box" the int, like this: class BoxedInt
value: int
def slider_int(label: str, value: BoxedInt) -> bool:
passor, I transmit the value by returning a tuple like this. def slider_int(label: str, value: int) -> Tuple[bool, int]:
passPresently the generated code uses snake cases, and transmits modifications via a tuple (in order to mimic pyimgui) |
|
Hehe, i was reading pull requests at pyimgui, saw your work, checked out your projects, ended up here. I see that you have already added mapping for imgui_internal. Super! Nice this auto-gen :) I have tested. I'm running 3.10.7 on Windows 10. Just a clean venv, Super to hear that you are planning to make this extensible with more and more submodules. Hopefully that'll be a reasonable undertaking for you as main maintainer, since its all autogenerated. I like the pyimgui compatibility, not only because that's where a bunch of your first customers will likely come from, but also because its more pythonic. The transformations compared to the C++ source are simple, rule-based and therefore predictable for the end user. So snake_case is a good idea. If i understand boxing correctly, then this is basically acting like a reference, modifying the value in-place, correct? There too it may be more pythonic to return the new value, a Python programmer wouldn't expect their values to be changed from underneath them. I looked a bit at that last commit, and saw some things:
choose one? I'll have a better look at HelloImGui next time i work on my C++ code again (totally different project). That may well be quite some months in the future :) But i am planning to start working on a second python program using imgui probably next month. By when do you think this is reasonably stable (in terms of naming and such at least) so that i can start using it? Thanks again for some really cool work! |
|
Hi, I just released some ImGui Bundle v0.6.4. I think the API is now stable. |
|
Thanks!
So all in all, this is working super well! |
|
Whoops, too fast, forgot to write about one larger issue. that HiDPI support. I saw your fac, but changing the global font scale (using the view menu in demo_all) leads to an ugly result: very blurry text. // 1. before opening the glfw window
float highDPIscaleFactor = 1.0;
float xscale, yscale;
glfwGetMonitorContentScale(glfwGetPrimaryMonitor(), &xscale, &yscale);
if (xscale > 1 || yscale > 1) {
highDPIscaleFactor = xscale;
glfwWindowHint(GLFW_SCALE_TO_MONITOR, GLFW_TRUE);
}
// 2. after creating imgui context (and before setup Platform/Renderer bindings, but i'm not sure if that's important)
if (highDPIscaleFactor > 1.f) {
ImGuiStyle& style = ImGui::GetStyle();
style.ScaleAllSizes(highDPIscaleFactor);
}This of course does not handle the case of dragging the gui between screens with different dpi, but its something at least. I solved that as well in a pyimgui program, as follows: def pos_callback(self, window: glfw._GLFWwindow, x: int, y: int):
if not glfw.get_window_attrib(self.window, glfw.ICONIFIED):
self.screen_pos = (x, y)
# check if we moved to another monitor
mon, mon_id = utils.get_current_monitor(*self.screen_pos, *self.screen_size)
if mon_id != self.monitor:
self.monitor = mon_id
# update scaling
xscale, yscale = glfw.get_monitor_content_scale(mon)
if scale := max(xscale, yscale):
self.size_mult = scale
# resize window if needed
if self.size_mult != self.last_size_mult:
self.new_screen_size = int(self.screen_size[0]/self.last_size_mult*self.size_mult), int(self.screen_size[1]/self.last_size_mult*self.size_mult)
# utils.get_current_monitor:
def get_current_monitor(wx, wy, ww, wh):
import ctypes
# so we always return something sensible
monitor = glfw.get_primary_monitor()
bestoverlap = 0
for mon in glfw.get_monitors():
monitor_area = glfw.get_monitor_workarea(mon)
mx, my = monitor_area[0], monitor_area[1]
mw, mh = monitor_area[2], monitor_area[3]
overlap = \
max(0, min(wx + ww, mx + mw) - max(wx, mx)) * \
max(0, min(wy + wh, my + mh) - max(wy, my))
if bestoverlap < overlap:
bestoverlap = overlap
monitor = mon
return monitor, ctypes.cast(ctypes.pointer(monitor), ctypes.POINTER(ctypes.c_long)).contents.valueThen whenever the scale changes ( |
|
Thank you very much for the detailed feedback. This is very useful to me. I'll come back to you in a few days |
|
Hello, Version v0.6.5 is available. It also solves the demo issues you mentioned, and adds lots of goodies. |
|
Hi! I have 0.6.5 pip-installed in Python 3.10.7, Windows 10. I tried running some demos included in the distribution, in the demos subfolder (so from For good measure i've tried a complete clean venv, same result. |
|
Ohhhhh... On my side, it does works, but I cannot fully reproduce your environment, since my Windows machine is actually a Windows ARM version (I'm running on a Mac M1 with parallels). Could you try to install from source and tell me if that works. I'm very interested in the results, and I would prefer it fail also in source mode, so that we can investigate. Could you please try this:
git clone https://github.com/pthom/imgui_bundle.git
cd imgui_bundle
git checkout v0.6.5
git submodule update --init --recursive
Then, open build/imgui_bundle.sln and build it (on my side, I build a windows ARM64 version. Your binaries will differ from mine). Build it, and try the 5 demo_xxx projects. Please tell me if they work or not.
runnerParams.backendType = HelloImGui::BackendType::Sdl;
HelloImGui::Run(runnerParams);
return 0;
}
// High DPI handling on windows & linux
// cf https://github.com/pthom/imgui_bundle/issues/7
{
float scaleFactor = mBackendWindowHelper->GetWindowDpiScaleFactor(mWindow);
params.appWindowParams.outWindowDpiFactor = scaleFactor;
if (scaleFactor > 1.f)
{
ImGuiStyle& style = ImGui::GetStyle();
style.ScaleAllSizes(scaleFactor);
}
}and then, try to run again the C++ demos. Any info from your side will greatly interest me! |
|
I followed your steps and compiled with this in release mode: Four of the c++ demos work fine (fonts are nice and crisp and properly sized on my screen with 250% scaling!) except some small cosmetic issues:
The demo_implot_markdown however shows the same pretty much black screen.
Build log:
When deleting the code block you quoted from
I do not quite see how that code block could mess things up, but i hope this is useful info. |
|
Ohhh... I guess you are a victim of the same internal compiler error as me. Extract from your logs: See https://developercommunity.visualstudio.com/t/MSVC-1933316300-Internal-Compiler-Err/10175047 Your compiler can fail with this simple hello-world like code: struct ImVec2
{
float x, y;
ImVec2(float _x, float _y) : x(_x), y(_y) { }
};
bool blah2()
{
auto f = [](const ImVec2 & size = ImVec2(0, 0)) -> bool
{
return true;
};
return f;
}This is a bug I reported to microsoft. PS: Could you also test to build on the |
|
I just updated msvc to 17.4.1, and no more internal compiler error. from python, v0.6.5, without the hidpi block all works fine with Last i just tried ref p.s., see here what i mean with the node editor demo showing things a bit big. opening it the first time, this is what i am greeted with: |
|
Hum... Not easy to solve if I cannot reproduce the issue. Would you be willing to give me sometime so that we can discuss this by telephone, and may be solve this via screen sharing? I think that a one hour session should be enough. If so, please contact my by email: pthomet@gmail.com |
|
The black screen issue is fixed by commit b67da43 (still in dev branch) |
pthom
added
the
faq
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi! I just came across this project and really like where it is heading. I'm currently using pyimgui and its not fully feature complete (complete enough that its only a minor inconvenience) and more importantly many releases behind. Since its all manual effort, this trouble likely remains.
Your effort here looks like a really good idea. Direct port (so no own flavor) of the great imgui, yet in a way that you can somewhat easily stay up to date with releases and various branches (docking!). Nice. And keeping all the docs intact, very nice.
I had some thoughts, perhaps some are just wrong because i'm not an expert on all of this.
Maybe i have missed it when looking around, but could you map imgui_internal.h as well (perhaps i missed it when having a look)? This is important for users of imgui who want to customize a little further, from something as simple as setting an item as disabled,
imgui.internal.push_item_flag(imgui.internal.ITEM_DISABLED, True), to building your whole own widgets. I like the idea of exposing that through a submodule like pyimgui does (see above example).Second, since i already have a working program using pyimgui (not yet on github), i'm at this stage firstly interested in getting the imgui bit of this effort. I think that means i would need the integrations bit (e.g. the glfw+opengl backend, though others may want to use one of the other backends). Is that something you envision providing? I guess they can't simply be autogenerated since one would have to mix and match a bit (like a C++ consumer of dear imgui would include
imgui_impl_glfw.cpp/.handimgui_impl_opengl3.cpp/.hin their program)? Or should this instead be converted to pure Python somehow? On a related note, i would also be cool to convert the demo window to pure python, so the whole autogenerated lib can be tested there, visually.Lastly, for the future, this nicely makes it relatively easy to wrap other libraries like you show with implot. It might be worth thinking about how that can be scalably provided, if you are interested. That people could add imnodes, one of the various file dialogues, etc. Perhaps through syntax like
pip install lg_imgui_bundle[imgui,implot,imnodes,xxx], selecting which they want. This repo can then provide the various submodules, kinda like vcpkg does. I'm viewing this from a high level, i'm not familiar with the intricacies of how to achieve that. Worth thinking about though, i think.Thanks for the great and interesting work!
The text was updated successfully, but these errors were encountered: