Improved GR framework support

[jheinen]

@tbreloff : Still some TODOs, but probably good enough to merge ...

TODOs:

• linetype: pie
• marker shapes
• multiple figure output
• animation stuff (will be difficult, because GR has builtin functionality for creating videos)

http://pgi-jcns.fz-juelich.de/pub/doc/ExamplePlots.html

[tbreloff]

These plots look really great! Thanks for the effort here... I'll merge when I have a chance.

On Jan 28, 2016, at 12:51 PM, Josef Heinen notifications@github.com wrote:

@tbreloff : Still some TODOs, but probably good enough to merge ...

TODOs:

linetype: pie
marker shapes
multiple figure output
animation stuff (will be difficult, because GR has builtin functionality for creating videos)
http://pgi-jcns.fz-juelich.de/pub/doc/ExamplePlots.html

You can view, comment on, or merge this pull request online at:

#117

Commit Summary

Print TODO messages for missing features
Added support for inline graphics (IJulia)
Fixed problem with uninitialized strings
Use Plots predefined colors
Implemented annotations
Implemented filled backgrounds
Added support for multiple marker colors / sizes
Changed default colormap
Added histogram output
Allow combination of lines and markers
Added horizontal/vertical linetype
Added support for bar plots
Added more line plots
Added support for two y-axis scales
Use SVG output for inline graphics (IJulia)
Improved representation of legends
Added support for subplots and further linetypes:
Added color bars and surface plots
Improved surface output
Added path3d and scatter3d functions
Added support for OHLC charts
Improved graphics state handling
File Changes

M src/backends/gr.jl (562)
M src/backends/supported.jl (7)
Patch Links:

https://github.com/tbreloff/Plots.jl/pull/117.patch
https://github.com/tbreloff/Plots.jl/pull/117.diff
—
Reply to this email directly or view it on GitHub.

[Evizero]

I agree! Looking forward to messing around with it. The lineplots look even nicer than ggplot2.

Have you tried using @manipulate?

[jheinen]

Glad to hear. But our main focus is on performance and interop ... 😄

[KristofferC]

Very nicely looking plots indeed.

[tbreloff]

I merged and did some very brief local testing. I think the biggest todo is to stabilize the plotting workflow as best as possible. I immediately ran into some errors which in hindsight I already knew about, but it would be good to keep them on the radar if they're fixable:

• if you manually close the plot window, it errors and you can't do any more plotting until you quit/reload. I close the window habitually, and this would probably mean I can't use it for real work until this is handled cleanly. I don't want to have to restart my session if I accidentally close a window.
• plotting 0 or 1 points results in errors. Seems silly, but there's lots of times I initialize a mostly empty plot window expecting to add to it later.
• some errors cause subsequent commands to complain with errors like "GKS: GKS not in proper state. GKS must be either in the state WSAC or SGOP in routine POLYLINE". It would be best to not allow it to get to this state, and a bonus to call some sort of "resetState" command when creating a new plot, so that past failed plotting commands don't force a session restart
• will it be possible to have more than 1 plot window open at a time? ideally plot(...) will open a new window

All told, I'm very happy that you decided to spend time on this, and if some of these issues are resolved I could see GR becoming a top choice for backend. Thanks!

[jheinen]

Problems 2+3 can be fixed with a simple sanity check in gr.jl.

Problems 1+4 describe the same problem - although GR can handle multiple graphics drivers (of different type) simultaneously, I'm still looking for a solution that fits best into GR's logical workstation concept, which is different from switching to a graphics backend.

I'll fix these problems with the next PR. I'm just waiting for an inspiring idea ...

[jheinen]

Have you tried using @manipulate?

@Evizero : now I did.

Thanks for the hint.

[Evizero]

I just tried it myself. Very nice!

I also tried to switch to the gr() backend for some of my own notebooks that I am working on and stumbled on some bugs (I assume)

For example copy doesn't seem to work as expected

using Plots
gr()
plt = scatter(randn(10), randn(10))
copy(plt)

@tbreloff @jheinen Since this PR is merged, how do you want to handle GR related issue reports? Do you want me to open new issues for each thing or should we create an umbrella issue for now?

[tbreloff]

So I'll be honest that I haven't reviewed the GR code in detail yet, which makes it hard for me to meaningfully solve individual issues. I think this could be up to @jheinen. One solution is to open separate issues (preferably with a "GR backend: " prefix to the issue's title), then I or @jheinen can close and consolidate to a single umbrella issue (probably #108) when needed.

I do know that there's probably a little overhaul that will be necessary to make sure all workflows are supported (multiple windows, copying plots, animations, embedded gui windows, etc)... but that this can be a gradual process. I think items that are related in terms of the solution (for example, multiple issues which require independent plot windows) should stay in one issue, and independent issues could live in their own issues.

[jheinen]

@tbreloff : Need some help with the show / display logic. gr.jl has two writemime methods and both (PNG + SVG) are called when a plot is finalized (results in two files gks.png and gks.svg). Can I set the defaultOutputFormat to something other than PNG, e.g. SVG? The PNG writemime method should only be invoked when the user calls savefig with a .png file extension.

Thanks in advance ...