JuliaGraphics
Move Makie Support to QMLMakie
This is probably not quite ready for a merge, but I'm starting a PR so we have a place to discuss where to go from here, and for visibility in case someone wants to play around with it or help out.
This PR moves the Makie Support to a new package, QMLMakie, as suggested in the roadmap and discussed in https://github.com/JuliaGraphics/QML.jl/issues/206.
This has a number of benefits:
- Decoupling the Makie integration from the QML version
- Possibility of
compatbounds - No need to rely on janky loading of
GLMakiewhich breaksPackageCompiler.jl
As it is, I basically just copied the code from makie_support.jl verbatim and made the necessary changes injlqml to initialize Makie Support in a separate JlCxx module, so that can be wrapped by QMLMakie.jl. There is still a lot of work to do before QMLMakie can be registered, but simple examples already work:
Thanks, tried it out and it works beautifully. Some comments:
- Could you split the commits in this PR in one commit to fix the white space consistency and one commit that has the actual change?
steffenhaug/QMLMakieshould probably be namedsteffenhaug/QMLMakie.jl- In your QMLMakie package, the module is named
QtMakiebut that should beQMLMakie
The last two points are of no infulence on this PR of course.
Thanks, tried it out and it works beautifully. Some comments:
Glad to hear :-)
Could you split the commits in this PR in one commit to fix the white space consistency and one commit that has the actual change?
Yeah, will do! I accidentally made the commit before i noticed the LSP had completely blown out the diff :-p
steffenhaug/QMLMakieshould probably be namedsteffenhaug/QMLMakie.jl
Agreed!
In your QMLMakie package, the module is named
QtMakiebut that should beQMLMakie
Oh yeah, nice catch. Thanks!
I ran JuliaFormatter on all the files in src while I was at it. That made for quite a large change technically unrelated to the PR. Let me know if that isn't desirable.
Also, if you have an opinion on style, we could add a JuliaFormatter config file to the project, so everyone is on the same page. As is, I just ran it with the default settings.
Hi @steffenhaug. Was wondering if you're still pursuing this? Thinking about starting a project using QML.jl and running into issues with compat with GLMakie. Seems like this would fix the issue.
Not really. I'm interested, but I hit some snags trying to get QMLMakie to support modern Makie versions, to the point where I could not justify the time investment on the clock, where I had a use case for it.
Even though embedding GLMakie is not that complicated in principle (as demonstrated by the ImGui embedding, the code is quite short), I have not been able to get modern Makie versions to render anything from a callback in QML, and I'm also not exactly sure what the problem is. Makie is not designed to run in multithreaded contexts, and I suspect that it doesn't play nicely with Qt's runtime.
I was hoping to get at least a proof of concept going before publishing anything, because publishing QMLMakie with a dependency on Makie 0.17 is silly, and alas I had not had time to work on this any further.
Even though embedding GLMakie is not that complicated in principle (as demonstrated by the ImGui embedding, the code is quite short), I have not been able to get modern Makie versions to render anything from a callback in QML, and I'm also not exactly sure what the problem is. Makie is not designed to run in multithreaded contexts, and I suspect that it doesn't play nicely with Qt's runtime.
How far did you get? In general, what is the furthest progress anyone has made in getting this to work: https://docs.makie.org/stable/explanations/backends/glmakie#embedding
Eg, has anyone gotten an empty plot (window, screen, figure, idk the correct term here) to show up without error?
Closing this because of the changes in #221, the new release #222 and https://github.com/steffenhaug/QMLMakie.jl/pull/1