I recently installed Julia on my Windows 10 machine using the given installer, opened cmd, then julia, added Plots package then did the following:
using Plots
gr()
plot(1:10)
A firewall permission message appeared asking if I’d grant permission to gksqt (which I’m sure is the gr plot window manager thing), but why does it ask for it?
The plot is shown with no error even if I don’t answer the firewall prompt.
Plots isn’t really using the socket GR is. I’m not 100% on WHY GR is using a socket but it is shown in the diagram:
@jheinen would be able to answer this better than I.
From my limited understanding, GR uses a separate driver program, gksqt.exe that acts as a server to manage the QT framework. The Julia package GR.jl communicates with gksqt.exe over network sockets in order to create plots. If you would like to avoid this, there are other GKS workstation types you can use.
You can find the source code for the GR framework here:
In particular, the code for gksqt is here:
Yes. GR needs the socket to communicate with GKS QtTerm, which in turn requires its own event loop. The same applies to the GKSTerm.app under macOS - here the driver must run even in a master thread. Whether there are other ways to implement this form of IPC under Windows is not known to me.
Thanks for the info @jheinen. Would be nice if there could be a fix at some point since it is “annoying” to always get the warning message (under macOS)
and having to manually “allow” it each time a new plot window is triggered.
Do you have the firewall enabled on your macOS system, or, did you already add exception rules?
Yes, I have the firewall enabled on macOS. I cannot add a rule as I the gksqt “app” is not available from within the firewall application options (adding a rule to Julia bundle does not fix the issue neither). gksqt only shows up in the firewall exceptions upon the pop-up window arrives and I click “Allow”.
Also ()this may be unrelated though) until very recently Plots.jl was triggering the GKS QTerm app while it triggers gksqt.
Is that the stock macOS firewall? I wonder if it will not prompt for this if we only listen for a certain local address.
Yes, it occurs with the macOS firewall (I have activated since years). Until recently there was no issue with Plots.jl and the GKS QTerm. But more or less in phase with the switch from Julia 1.5.4 to Julia 1.6 the GKS QTerm now became gksqt and prompts for firewall access all the times (highly annoying). Also, it seems gksqt is a corrupted version of GKS QTerm since one cannot close it without having to quit and the interaction with Julia is less stable (more crashes then previously).
Ah, well it might be the switch to using GR_jll.jl rather that the GR tarball.
This will switch you back to the tarball version of the binaries.
julia> ENV["JULIA_GR_PROVIDER"] = "GR"
(@v1.6) pkg> build GR
You can figure which binary provider you are using by checking the value of GR.gr_provider[]. The two valid values are either “BinaryBuilder” (GR_jll) or “GR” (tarball).
If that fails you can try reverting GR to an earlier version such as v0.55.0. That can be done using the following command:
(@v1.6) pkg> add GR@v0.55.0
It would be best to file an issue at GR.jl/GR.jl at master · jheinen/GR.jl · GitHub so the problems you are having can be documented and tracked.
Thank you for your post 
!
This fixes both GKS QtTerm “deprecation mode” issue and also does no longer prompt for firewall access.
Before reverting to v0.55.0 I tried with both suggested JULIA_GR_PROVIDER but this did not impact the behaviour of plotting. I will file an issue as suggested so a fix could be found for the latest version.
At least you have a temporary solution.
I would suggest giving ENV["JULIA_GR_PROVIDER"] = "GR" another try and rebuilding the latest GR and confirming GR.gr_provider[] has the right value. This would at least allow us to confirm that something changed with the tarballs between v0.55.0 and v0.57.x. @jheinen might be able to hunt down what is causing the issue.
What version of macOS are you using?
I am running on macOS 10.15.7.
Now I am confused as all seems to work the fine (having ENV["JULIA_GR_PROVIDER"] = "GR") since I downgraded GR and upgraded it again.
I wanted to test with GR_jll.jl but setting ENV["JULIA_GR_PROVIDER"] = "BinaryBuilder" may not be the way doing it ?
So now you are using GR v0.57.4 with ENV["JULIA_GR_PROVIDER"] = "GR" and everything works fine?
Yes.
But this setting was also what I had before forcing GR v0.55.0 and upgrading it again and then it did not work properly.
EDIT: the only difference is that previously I did not have explicitly package GR added but it came shipped with Plots.
Another Mac user here. Solved by changing the JULIA_GR_PROVIDER as suggested, without having to downgrade/upgrade GR. Thanks
Hi dear expert,
I followed everything you said and plotting OK. But my avast anti-virus program caught gksqr.exe that it is infected by IDP.Generic virus… I did not put it in quarantine but allowed an exception by ignoring it… I hope I did right. what do you say Sir?
I am using Julia 1.8.0 on windows 10
and why is julia plot taking more time than actually solving differential equation? I really don’t get it !!!
It’s because the UI is using sockets to communicate.
For faster plots, try using PackageCompiler or use a persistent Julia session.
https://julialang.github.io/PackageCompiler.jl/dev/examples/plots.html