How do you stop using Immerse without quitting/restarting julia
lewisl opened this issue · comments
You might want an interactive plot and then you want to output to file or to browser tab. Need some stop using command.
Output to a file is easy: just hit the "saveas" icon in the toolbar. (The default Gtk icons on OSX seem very non-intuitive, see JuliaGraphics/Gtk.jl#184.)
Output to a browser tab is harder, unless we use a different name than plot for this function. CC @dcjones. Out of curiosity, what's the motivation for switching between a browser tab and a Gtk window?
Not sure, but I could imagine someone may want to use Immerse but also the zooming/panning/toggling built into the SVGJS backend which only works through a browser.
@timholy Actually, I don't want to switch from gtk window to browser. It's one or the other. The code is an exercise that students will complete. I am trying to minimize the dependencies that need to be installed. PlyPlot works best (matplotlib is very mature), but there is a lot to install. Winston has problems. So, plots w/gadlfy seemed good: plots api is easier than ggplot. But, launching the browser, while ok since everyone has one, seems a bit disruptive (unless you could specify new window, which alas you cannot).
Next, I saw immerse. Very similar experience to matplotlib/PyPlot. The gtk window is a bit off on OS x, but gadfly defaults look a bit better than matplotlib defaults. But, the dependency stack is even worse and the install time almost unbearable.
At least Python is known to be reliable and the mini-conda install simplifies dependency management (don't know--have full Python install already on my machine).
Some day we really need native plotting in Julia with "native" backends (not gui portability libraries from 'nix) on Mac and Windows. "Native" doesn't exist on linux so you have to pick a library and probably install it. But anyone choosing 'nix is proud of suffering--and they'll already have at least on gui library installed already. It just means that supporting plotting on 'nix will require supporting multiple gui libraries.
For minimal dependencies, I would also consider UnicodePlots (depending on plotting complexity). I'm in agreement about dependencies... it's a problem that should improve over time.
I'm biased, but you should consider https://github.com/tbreloff/Plots.jl, as you can access all of the plotting packages mentioned here, plus Qwt.jl. Your students can each pick the backend that is easiest for them...
OK, so it sounds like we don't actually need to be able to switch between Gtk outputs and browser outputs. Presumably we can close this?
I'm totally with you on the awfulness of binary dependencies. It will be true even if we use native libraries, however (see, e.g., JuliaImages/Images.jl#291). Perhaps it would be less awful?
yes, close switching.
Binary dependencies that are “native” would be less awful as less large. On OS X, you’d need to bind to cocoa and that probably needs more than just ccall from Julia. But, the binaries would be much smaller as most of the runtime would be present. When Julia x.x can statically compile someday (saw this in a random Stefan post…) then maybe the c glue code wouldn’t be needed at all.
Also, and this is beyond the scope of either Plots or Immerse, the package manager needs some concept like Python “wheel” or Homebrew “bottles” for pre-built binaries. Sure, there is a management problem for the package maintainer: you’ll need a “bunch” of those binaries. But, if you just target Mac 64 bit, Windows 32 bit, and Windows 64 bit it is not so many. The ‘nix guys get to build theirs (real men “make”). Sure, this is a pain but it works great for Python (pip > 6). Were some real growing pains as maintainers figured out what they needed, did clean compiles, organized their repos. But, after 6 months it was clean. Really the maintainer should do the compiles: only someone who knows the code can fix errors and decide which warnings to ignore. And it’s one person doing the builds rather than thousands.
I think the Julia team wants Julia to be used and coding to be the code that solves users’ problems, written in high level Julia. Users shouldn’t have to do c or git hacking.
Of course, there are real contributors who want the code and want to build it, with changes. The src will be in the git repo or in a downloadable archive.
But, this is for whoever owns Pkg and its sundry machinery.
On Oct 27, 2015, at 11:36 AM, Tim Holy <notifications@github.commailto:notifications@github.com> wrote:
OK, so it sounds like we don't actually need to be able to switch between Gtk outputs and browser outputs. Presumably we can close this?
I'm totally with you on the awfulness of binary dependencies. It will be true even if we use native libraries, however (see, e.g., JuliaImages/Images.jl#291JuliaImages/Images.jl#291). Perhaps it would be less awful?
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/19#issuecomment-151603871.
Just a quick note on binary deps, then you can close.
My eventual goal with Plots and similar initiatives is to gradually separate interface and functionality away from the low-level implementations so that, at some point, the low level could be easily swapped out. In this case, it could be potentially straightforward to have a minimal wrapper around Quartz calls, and have everything else work as expected. Compose already does this to some extent for example... it's just a matter of simplifying the process (and of course someone needs to actually write/test the code)
That would be great. harder on Windows, but also possible.
Thanks.