Open mkitti opened 1 year ago
Perhaps this was proposed in the past via #339 : https://github.com/barche/GR.jl/blob/e00e1272678c85d0cbc0092f4608240d3f99c73f/src/GR.jl#L323
I'll dig more to see if this was ever actually implemented.
We used to kind of do this way on Windows... https://github.com/jheinen/GR.jl/commit/813fba7c2731751701628f3c366990182c7718b2
gksqt(gkscmd -> run(`gksqt`; wait=false))
However, that function completely ignored the gkscmd
argument being passed in. It should have looked like this as in #339:
gksqt(gkscmd -> run(`$gkscmd`; wait=false))
Yes - we used this solution in the past. Unfortunately, it fixes the problem for Julia only. I remember we used an empty GKS_QT
environment to indicate that gksqt
/ gksqt.exe
should be started within the Julia wrapper. But that also had some kind of problems - I can't remember them. At the moment, I am relieved that the Windows DLL odyssey seems to have come to an end.
I appreciate your contributions.
I appreciate your willingness for me to experiment to find solutions here.
My thoughts here stem from https://github.com/jheinen/GR.jl/issues/490#issuecomment-1326895285 where we seemed to have a persistence issue and a user had to reset their computer. My hypothesis there was that gksqt.exe from the original configuration was still running even though the user changed configurations and restarted Julia.
If you can rule out that possibility, I would appreciate that. How is the gksqt.exe process stopped or restarted?
There seems to be some need to control the gksqt process in some scenarios: https://github.com/gentzkow/template/issues/67#issuecomment-1287579628
We may want to use the following to execute
gksqt
in the future when using GR_jll.This builds the environment for
gksqrt
via JLLWrappers: https://github.com/JuliaPackaging/JLLWrappers.jl/blob/f6f6abe972085c08072f5d61df1cf7e4746da84b/src/products/executable_generators.jl#L19-L30Via
withenv_executable_wrapper
this usesBase.withenv
.