Replies: 16 comments 71 replies
-
imgui.movHere is a docking-multiviewport demo. You could also test it locally: |
Beta Was this translation helpful? Give feedback.
-
Of course I am fine with that. Just want to leave an appreciation note here for your hard work! Thank you for your awesome efforts! |
Beta Was this translation helpful? Give feedback.
-
|
I'm not much of a developer but I hope I will be able to help with some examples. Please let me know how I can help with this topic. And as for the breaking change, no worries. Thank you very much for the hard work put into this package! |
Beta Was this translation helpful? Give feedback.
-
|
I can help adopting imgui and implot examples to work with tables and new api. In general, I think ImGui is underestimated as a working solution for writing GUIs in Julia. Maybe we can provide more pure Julia examples of compleх GUI to gain more popularity. Especially with interactive stuff where using other GUI libraries get overcomplicated. As for GLMakie backend, for me it seems like it should be in opposite way - CImGui.jl should have some wrappers for Makie plots widget. |
Beta Was this translation helpful? Give feedback.
-
That would be great! I've sent you an invitation so you can get things merged quickly in related repos. |
Beta Was this translation helpful? Give feedback.
-
|
Everything looks good but I'm not sure I agree about putting all the generated wrappers into one namespace with default Clang.jl output. At least for cimplot, this makes a lot of work for any user since all the plot functions, and subvariants of those plot functions, are templated. I don't mind splitting out When I find another chunk of time, I intend to use a combination of the metadata output from cimplot and ExprTools.jl to craft a more robust version of the extra pass that I currently do during wrapper generation. The metadata output by the cimplot generator is the same form for cimgui and other extensions. Therefore, if I write this well enough it could be useful to all. At least with |
Beta Was this translation helpful? Give feedback.
-
|
To me, those plot functions can also be generated as: where The point here is to make the maintenance process easier for new users/contributors. If some users would like to try something new that is not currently supported and the main maintainers don't have time at the moment, those users can quickly update upstream packages 2., 3., 4. by themselves and may add their manually written wrappers to get things to work. In the end, they may submit a PR and become a contributor. I think it's OK to separate each extension library into an isolated module with its own generator.jl script, but this generator script should be simple, simple enough that the new users should not get stuck in this step. Especially, when something goes wrong, they can figure out a fix on their own. However, generator scripts for generating high-level wrappers are generally not easy to maintain. Even for the package author, it takes a chunk of time to make everything right. |
Beta Was this translation helpful? Give feedback.
-
|
I would also like to thank you for all of your work on CImGui. However, I've just recently started using it, and so some of what you talked about doesn't make sense, lol. Breaking changes are fine with me because i have almost no code other than simple examples written so far. This package solves a lot of potential problems that I see involving Julia and graphics and gui's and I very much agree with @sairus7 that it is very underestimated as a solution for gui applications . Gtk is so much work and far too heavyweight for what i want to do. I need something that interfaces to OpenGL easily and cleanly. CImGui seems to really fit well for what i want to do. I do find Dear ImGui to be really unintuitive in some situations therefore more examples are always welcome and I am happy to contribute examples. |
Beta Was this translation helpful? Give feedback.
-
Indeed. Another reason why I prefer to use ImGui is that I don't like those fancy things like reactive programming and my brain hurts when doing the signal-slot pattern with observables. I guess the naive way documented in #39 can cover 80% of the use cases in practice. |
Beta Was this translation helpful? Give feedback.
-
|
Oh, I should also add that i can't contribute to helping with the actual CImGui project at this time but only because i'm not very familiar with the library. As i become more familiar with it i believe i will be able to help. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Gnimuc , what is the status of this transition? By the way, it would be cool if you could tag a new release that supported the docking branch. |
Beta Was this translation helpful? Give feedback.
-
|
I've been using master branch for my projects a lot and haven't encountered any issues. Do tell if you need some help! |
Beta Was this translation helpful? Give feedback.
-
|
@pxl-th I have invited you as a collaborator. Feel free to make any changes you needed to tag 1.82. |
Beta Was this translation helpful? Give feedback.
-
|
Actually for my use cases it all works fine as is, so I'd just go and tag a release if you are fine with that? |
Beta Was this translation helpful? Give feedback.
-
|
Yes. But before tagging a new version, we should at least update the README. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe we should also start using semantic version for CImGui.jl? |
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone :) I recently bit the bullet and started updating things for the latest versions of ImGui and ImPlot. I've already opened a bunch of PRs, I'll list them here for completeness (in roughly the order they ought to be merged):
I've tested all of these locally and the demos seem to work fine with no regressions. I have absolutely no idea how to handle versioning/compat bounds for all of them 🙈 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @Gnimuc for bumping the CImGuiPack.jll version 😅 Am I correct in thinking that the plan should now be:
I must say the lack of semver is really biting us here 😬 Does it make sense to have strict compat bounds? |
Beta Was this translation helpful? Give feedback.
-
|
Uhh I'm dumb, I forgot I already made a 1.89.4 release for LibCImGui.jl. Should we yank that and make a new one with JuliaImGui/LibCImGui.jl#6? |
Beta Was this translation helpful? Give feedback.
-
|
@JamesWrigley is there any caveat to tag a new version 1.89.5? |
Beta Was this translation helpful? Give feedback.
-
|
I suppose the new patch version will always be upgraded, so finally the buggy 1.89.4 will be "yanked" automatically. |
Beta Was this translation helpful? Give feedback.
-
|
I think the only reason not to would be to stay in sync with imgui upstream. I'm not sure how important that is to us, but if the intention is to keep LibCImGui.jl as the 'base' package that others build off of then I'm inclined to stick with upstream. But that could be annoying. Maybe we could only commit to keeping the major/minor versions in sync with upstream and keep the patch number for ourselves? (possibly confusing) |
Beta Was this translation helpful? Give feedback.
-
I guess it's ok to not sync the patch number because Dear Imgui rarely introduces breaking changes between patch versions. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, that sounds good to me 👍 I'll prepare some PRs for the new release. |
Beta Was this translation helpful? Give feedback.
-
|
Alrighty, opened a bunch of new PRs. These ones bump package versions to work with new LibCImGui.jl versions:
And these ones restrict compat bounds to the old versions of the above packages so we don't break things too much (in hindsight this is probably the first thing I should've done): Does that look right? Not an expert with this stuff 😅 |
Beta Was this translation helpful? Give feedback.
-
|
I don't think this package has many users, so as long as there are no more new compatibility issues, I suppose we are not breaking things. 😅 |
Beta Was this translation helpful? Give feedback.
-
|
Ok, all the dependencies have new versions 👍 I think CImGui.jl and ImPlot.jl should have a minor release with those PRs I made to make sure they pull the right versions. Apart from that, I think #87 and JuliaImGui/ImPlot.jl#27 are ready to be merged. |
Beta Was this translation helpful? Give feedback.
-
|
At last, all PRs merged 🎉 Thanks everyone for the help ❤️ |
Beta Was this translation helpful? Give feedback.
-
|
Are there any objections to me merging the cimgui-pack and LibCImGui repos into this one, similar to how Makie.jl has sub-projects for GLMakie/CairoMakie? The reason is because I find switching between the repos very annoying and I think it's easier to have them all in one place because they're all quite tightly related to each other. Also, how do we feel about dropping the adherence to ImGui's versioning? Managing breaking changes is kinda a pain, and I think it would end up being better for downstream users if we adopted semantic versioning. |
Beta Was this translation helpful? Give feedback.
-
|
Lol, I guess |
Beta Was this translation helpful? Give feedback.
-
|
BinaryBuilder doesn't support taking source code from different repos? https://github.com/JuliaPackaging/Yggdrasil/blob/master/C/CImGuiPack/build_tarballs.jl |
Beta Was this translation helpful? Give feedback.
-
|
It's not BinaryBuilder, it's Pkg and the general registry: JuliaRegistries/General#109914 |
Beta Was this translation helpful? Give feedback.
-
|
I mean, if you can manually list cimgui, cimnodes and cimplot repos with commit hashes in |
Beta Was this translation helpful? Give feedback.
-
|
Yeah but it's not just those anymore, it's also all the test engine stuff which is quite a few files. I think it's easier to have it in a separate repo. |
Beta Was this translation helpful? Give feedback.
-
|
People! I'm attempting to deprecate our custom GLFW/OpenGL backends in favour of the official backends in #122. It works on my Linux system, but I would very much appreciate it if other folks could follow the instructions in the PR to test it locally on your systems :) In particular OSX and Windows. Note that only Also, who's using the opengl 2 backend? @jpsamaroo /@IanButterworth? |
Beta Was this translation helpful? Give feedback.
-
|
Oh, and another consequence from having separate LibCImGui - ImPlot package depends only on LibCImGui, but not CImGui. Those two packages (CImGui and ImPlot) are treated as separate wrappers around LibCImGui, with the potential to make someone's own wrapper. It seems to me that nobody will do that, as long as the wrapper remains quite straightforward (types and function signatures are preserved). So maybe even ImPlot can be merged here?.. |
Beta Was this translation helpful? Give feedback.
-
Agreed, I added a
Agreed, that's how I merged it in 72d4ca7.
That shouldn't change much :) It'll be
Mmmm, we could but I don't think that's necessary. ImPlot.jl is kinda a lot of code to add to the package, and I imagine many users won't need it. I think it's fine for ImPlot.jl to depend on CImGui and use the |
Beta Was this translation helpful? Give feedback.
-
|
Hi @JamesWrigley !
My renderer functions changesmodule Renderer
using CImGui
using CImGui.ImGuiGLFWBackend
using CImGui.ImGuiOpenGLBackend
using CImGui.ImGuiGLFWBackend.LibGLFW
using CImGui.ImGuiOpenGLBackend.ModernGL
using ImPlot
using CImGui.CSyntax
import CImGui.ImGuiGLFWBackend: ImGui_ImplGlfw_ErrorCallback
function __init__()
glfwDefaultWindowHints()
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3)
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 2) # ??? on some Windows machines 3.0 would crash, so I've changed to 3.2 everywhere
@static if Sys.isapple()
global glsl_version = 150
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE) # 3.2+ only
glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, true) # required on Mac
else
global glsl_version = 130
end
end
#? error_callback(err::GLFW.GLFWError) = @error "GLFW ERROR: code $(err.code) msg: $(err.description)"
const INI_PATH = joinpath(@__DIR__, "..\\imgui.ini")
# ??? Here I setup initial ImPlot, theme, docking, resolution, fonts etc. How would I do that in new version?
function init_renderer(width, height, title::AbstractString)
glfwSetErrorCallback(@cfunction(ImGui_ImplGlfw_ErrorCallback, Cvoid, (Cint, Ptr{Cchar})))
# create window
window = glfwCreateWindow(width, height, title, C_NULL, C_NULL)
@assert window != C_NULL
glfwMakeContextCurrent(window)
glfwSwapInterval(1) # enable vsync
# setup Dear ImGui context
ctx = CImGui.CreateContext()
ctxp = ImPlot.CreateContext() #
ImPlot.SetImGuiContext(ctx)
io = CImGui.GetIO()
io.IniFilename = Base.unsafe_convert(Cstring, INI_PATH)
# setup Dear ImGui style
CImGui.StyleColorsDark()
# setup Platform/Renderer bindings
glfw_ctx = ImGuiGLFWBackend.create_context(window, install_callbacks = true)
opengl_ctx = ImGuiOpenGLBackend.create_context(glsl_version)
ImGuiGLFWBackend.init(glfw_ctx)
ImGuiOpenGLBackend.init(opengl_ctx)
# enable docking
io = CImGui.GetIO()
io.ConfigFlags = unsafe_load(io.ConfigFlags) | CImGui.ImGuiConfigFlags_DockingEnable
### DPI for 4К
basic_h = 1080 # basic_w 1920
mode = glfwGetVideoMode(glfwGetPrimaryMonitor())
w = unsafe_load(mode).width
h = unsafe_load(mode).height
dpi_scale = h / basic_h
style = CImGui.GetStyle()
CImGui.LibCImGui.ImGuiStyle_ScaleAllSizes(style, dpi_scale)
# io.FontGlobalScale = dpi_scale
# fonts
fonts = unsafe_load(io.Fonts)
ranges = CImGui.GetGlyphRangesCyrillic(fonts)
CImGui.AddFontFromFileTTF(fonts, "C:\\Windows\\Fonts\\tahoma.ttf", 16 * dpi_scale, C_NULL, ranges);
return window, ctx, glfw_ctx, opengl_ctx
end
function renderloop(v, window, ctx, glfw_ctx, opengl_ctx, ui=()->nothing, hotloading=false)
try
while glfwWindowShouldClose(window) == 0
glfwPollEvents()
ImGuiOpenGLBackend.new_frame(opengl_ctx)
ImGuiGLFWBackend.new_frame(glfw_ctx)
CImGui.NewFrame()
hotloading ? Base.invokelatest(ui) : ui()
CImGui.Render()
glfwMakeContextCurrent(window)
width, height = Ref{Cint}(), Ref{Cint}() #! need helper fcn
glfwGetFramebufferSize(window, width, height)
display_w = width[]
display_h = height[]
v.w = display_w
v.h = display_h
glViewport(0, 0, display_w, display_h)
glClearColor(0.2, 0.2, 0.2, 1)
glClear(GL_COLOR_BUFFER_BIT)
ImGuiOpenGLBackend.render(opengl_ctx) #ImGui_ImplOpenGL3_RenderDrawData(CImGui.GetDrawData())
glfwSwapBuffers(window)
yield()
end
catch e
@error "Error in renderloop!" exception=e
Base.show_backtrace(stderr, catch_backtrace())
finally
ImGuiOpenGLBackend.shutdown(opengl_ctx) #ImGui_ImplOpenGL3_Shutdown()
ImGuiGLFWBackend.shutdown(glfw_ctx) #ImGui_ImplGlfw_Shutdown()
CImGui.DestroyContext(ctx)
glfwDestroyWindow(window)
end
end
function render(ui; width=1280, height=720, title::AbstractString="Demo", v, hotloading=false)
window, ctx, glfw_ctx, opengl_ctx = init_renderer(width, height, title)
GC.@preserve window ctx begin
t = @async renderloop(v, window, ctx, glfw_ctx, opengl_ctx, ui, hotloading)
end
return t
end
end # module |
Beta Was this translation helpful? Give feedback.
-
|
Cool, glad it's working :)
Yes, and at some point when I'm confident they're not needed anymore I'll archive the repos.
Correct, that's still on my todo list 🛠️
I see 🤔 OpenGL 3.0 is 16 years old now so I think it's safe to bump the minimum to 3.2, but I can add support for setting a minimum OpenGL version too.
As far as I can tell you can set all of those imgui settings (except the minimum OpenGL version) before calling ctx = ig.CreateContext()
pctx = ImPlot.CreateContext()
on_exit = () -> ImPlot.DestroyContext(pctx)
ig.render(ctx; on_exit) do
....
endBTW for the DPI scaling, you can get the monitor resolution like this with GLFW.jl: import GLFW
width, height = GLFW.primarymonitorresolution() |
Beta Was this translation helpful? Give feedback.
-
Actually that's not quite accurate, lemme clarify: we're now using the official imgui GLFW/OpenGL backends, but the renderloop and helper functions around them (i.e. to create image textures) are in package extensions. |
Beta Was this translation helpful? Give feedback.
-
|
I'm getting around to updating this for ImGui 1.91.0 (#141), and I'm gonna try generating the wrappers automatically like @wsphillips did with ImPlot.jl. This should be possible to do kinda-sorta-nicely because cimgui supports parsing comments, which I enabled here: JuliaImGui/cimgui-pack#4 There's two ways we could do this:
Any opinions on which would be better? I don't have a strong preference. |
Beta Was this translation helpful? Give feedback.
-
|
Those ig* prefixes appear in C API just because C has no namespaces, right? I think it can be hidden, just like explicit constructor / destructor type / argument type / return type declarations in method names - those are just C API shenanigans. Of course if type dispatch can be handed properly. Also, from user perspective, it is awkward to have two separate modules / namespaces for a single library, with some names only found in lower level, like: CImGui.LibCImGui.ImGuiStyle_ScaleAllSizes
CImGui.LibCImGui.igDockSpaceOverViewport
CImGui.LibCImGui.ImGuiTableFlags_BordersOuter
# or
import ImPlot.LibCImGui: ImGuiCond_Once, ImGuiCond_AlwaysI'd prefer they all be exported / mapped into CImGui module, so user would never need to call low-level library. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah that's fair, I'll see what I can do 🐙 |
Beta Was this translation helpful? Give feedback.
-
|
Alrighty, the wrappers are a bit more fleshed out now: https://github.com/Gnimuc/CImGui.jl/blob/v1.91.0/src/wrapper.jl I realized it's a bit awkward to do 2) because parts of the headers (in particular |
Beta Was this translation helpful? Give feedback.
-
|
Well... that was way harder than I thought it would be. 'tis done and merged now though, and the tests have been expanded to exercise the majority of the demo. If any of you have the time to |
Beta Was this translation helpful? Give feedback.
-
|
What do y'all think of this thing? https://juliaimgui.github.io/ImGuiDocs.jl/cimgui/stable/ |
Beta Was this translation helpful? Give feedback.
-
|
Cool! With these docs, I don't need to look for API functions in imgui sources. |
Beta Was this translation helpful? Give feedback.
-
|
Alrighty, all links have been changed to point to the new site :) |
Beta Was this translation helpful? Give feedback.
-
|
@JamesWrigley |
Beta Was this translation helpful? Give feedback.
-
|
Sure, go ahead :) |
Beta Was this translation helpful? Give feedback.
-
|
I wrote a note, feel free change it |
Beta Was this translation helpful? Give feedback.
-
|
Looks great, thanks ❤️ |
Beta Was this translation helpful? Give feedback.
-
|
Oh, just saw it was already published, so I will move the note to the next month. |
Beta Was this translation helpful? Give feedback.
-
Hi,
As you might notice, this package, CImGui.jl, has got stuck in v1.79 for about 7 months. The main reason is that Dear ImGUI introduced a new set of table APIs in v1.80 and it's a bunch of work to update the wrappers and examples. Another reason is Clang.jl. Until recently, Clang.jl had no support for handling C's forward declaration, so I had to manually tweak the auto-generated bindings from time to time, which was quite annoying.
In the last few months, I redesigned and reworked Clang.jl so that one can now regenerate bindings with a single click. However, I adopted a new way for dereferencing pointers and as a result, almost all example codes need to be updated.
For example,
igGetIO()returns a pointer of typePtr{ImGuiIO}. With this field access method in v1.79, say we haveio::Ptr{ImGuiIO}=igGetIO(), then we can runds = io.DisplaySizeto get a valuedsof typeImVec2. This may look handy at the first glance. But, it does not support chaining, for example,io.DisplaySize.xcannot work as expected and it's not trivial to make it work in an efficient way. The new field access method generated by Clang.jl now returns a pointer instead of a value.io.DisplaySize.xwill return a pointer and one needs to explicitly writeunsafe_load(io.DisplaySize.x)to get the value. In this way, we're able to read/load/copy a single value from a big nested struct without copying the whole struct object from C to Julia. So, I think it's worth reworking everything in this new style.Adding support for docking-multiviewport has been in the feature request list for a loooong time(#34). To be honest, the docking feature is the reason why I adopt Dear ImGUI at the very beginning. I've been waited for this feature to be officially released for over two years, but it seems that there are still a few severe bugs on certain platforms and no one is currently working on them, so the development is kinda suspended. On the other hand, the docking branch of Dear ImGUI is relatively stable and is being used by many projects. In #43, @yamen suggested that we should switch to the docking branch and also integrate
ImPlotfor the sake of compatibility and I think this is the right direction.In the last week, I started to rework the whole package to make it easier for long time sustainable maintenance:
CImGuiPack_jll. Its major version and minor version should always be the same as the Dear ImGui version used incimgui-pack. As a result, we can enforce semantic versioning in high-level packages likeCImGui.jlandCImPlot.jlwithout losing the version info of the Dear ImGui. This package is fully auto-generated by using Clang.jl with this generator script: https://github.com/JuliaImGui/LibCImGui.jl/blob/master/gen/generator.jl. The above-mentioned field access methods for certain types will be generated as long as the type name is in this list. (Requirements for maintaining: know how to install Julia package and run Julia script.)ImPlot.The next release(v1.82.0) of CImGui.jl will be breaking, but since it doesn't have many users, I guess it's just OK to not follow the semantic versioning at least for this release.
Anyway, the future direction is definitely to strictly follow semantic versioning. The following list contains the things, I think, that need to be improved before the v2.0.0 release:
Sorry in advance if this is disturbing, but you guys seem to be the only users of this package, any thoughts would be appreciated! :)
cc @jpsamaroo @sairus7 @iuliancioarca @PinkMushroom @IanButterworth @wookay
Beta Was this translation helpful? Give feedback.
All reactions