Open aashish24 opened 8 years ago
@aashish24 Actually, we can plot data using plot
, boxfill()
, isofill()
, isoline()
, vector()
, meshfill()
, vector3d()
, scalar3d()
, dual_scalar3d()
(:confused:) , oned()
, xvsy()
, xyvsy()
, yxvsx()
, and I probably missed a few. I'm pretty sure these are commonly used by our users as shortcuts for the whole getgraphicsmethod
-> plot
process, though we'd have to have @doutriaux1 chime in on that.
@aashish24 Actually, we can plot data using plot, boxfill(), isofill(), isoline(), vector(), meshfill(), vector3d(), scalar3d(), dual_scalar3d() () , oned(), xvsy(), xyvsy(), yxvsx()
Yup, I know. I was referring to boxfill()
as an example (should have been more clear). But that's the thing, who uses these calls (none of our tests or other scripts I have seen using these). Most of them used plot()
.
I would like to favor smaller, simple, non-redundant API as much possible.
I know that @doutriaux1 uses them extensively when tinkering on the command line :smile: I think this is the kind of thing we should try and get some metrics on. I really need to bring the analytics server back online; I'll try and clear some time to do that in the next week or two.
@chaosphere2112 I never use boxfill()
and co. I actually strongly agree with @aashish24 on this one, we should get rid of them all, all they do anyway is call plot
now if you want to get fancy and keep a similar approach, I would recommend actually implemeting a .plot()
function on the graphic methods themselves.
import vcs
x=vcs.init()
gm = x.createboxfill()
gm.plot(data)
I would recommend actually implemeting a .plot() function on the graphic methods themselves.
:+1: that would nice since that will make the code compact.
createisofill().plot(data['clt']) # Create default canvas if none provided
There are two things in my mind really:
I certainly agree that they add a lot of cruft. I guess we'd have to leave the canvas.createisofill()
etc. and associate the created GM with the canvas for plot()
on GMs to work, but that's not a big deal.
I certainly agree that they add a lot of cruft. I guess we'd have to leave the canvas.createisofill() etc. and associate the created GM with the canvas for plot() on GMs to work, but that's not a big deal.
Totally agree :smile:
@aashish24 @doutriaux1 +2 to using just a plot function. Moving plot on the gm from canvas is not a clear cut. Now you have
x=vcs.init() gm = x.createboxfill() x.plot(gm) x.clear()
which makes sense as well. Keeping this the same maintains a lot of the compatibility.
Okay, baby steps first:
plot
calls alternative@danlipsa I don't think we should get rid of x.plot()
at all. Just add gm.plot()
as a convenience function which would be better located than x.boxfill()
@doutriaux1 This reminds me of Perl vs Python. Perl: there is more then one way of doing it. Python: There should be one — and preferably only one — obvious way to do it. We know who won here :smile:
x=vcs.init() gm = x.createboxfill() x.plot(gm) x.clear()
@danlipsa look at this code. (based on @doutriaux1 suggestion)
import cdms2, vcs
data = cdms2.open('clt.nc')['clt']
vcs.init().createisofill(data).plot()
Done
I agree that duplicates are bad but since canvas and graphics methods are related and drawable entities it is okay to have plot method in both of them. For instance
vtkRenderWindow and vtkRender they both has Render() method.
In GeoJS
map, layers, and features all have draw() method.
Also you can do this now
import cdms2, vcs
data = cdms2.open('clt.nc')['clt']
vcs.init().plot(createisofill(), data)
The difference is subtle but it breaks the flow somewhat. Since isofill is connected to canvas anyways, you should be able to call plot on isofill and that should trigger the rendering too. I think it is a general use-cased and used in libraries like d3 and geojs quite a bit.
@doutriaux1 @aashish24 We can add that if you like it. :smile: It will be just a one line function anyway.
@aashish24 the only issue with your line is that it is really:
import vcs
x=vcs.init()
gm=x.createboxfill()
gm.plot(data)
And gm
does not know about x
object so it will likely create one under the hood, so your line actually creates a useless x and can be shortened/optimzed to:
import vcs
vcs.createboxfill().plot(data)
that actually brings the question, should gm.plot(data)
return the canvas it used?
import vcs vcs.createboxfill().plot(data)
cool! Yes this would be preferred! Sounds good, I will add the plot method to graphics classes for 3.0.
@doutriaux1 Above:
chaosphere2112 I guess we'd have to leave the canvas.createisofill() etc. and associate the created GM with the canvas for plot() on GMs to work, but that's not a big deal.
We can just do what vcsaddons
does and add a canvas argument, so the canvas.create$GRAPHICSMETHOD functions will pass the canvas in as an additional arg to the GM.
hat actually brings the question, should gm.plot(data) return the canvas it used?
It should return the gm itself so that you can chain it for other calls too like in d3. I prefer it returns itself vs canvas since that would be bit off.
It should return the gm itself so that you can chain it for other calls too like in d3. I prefer it returns itself vs canvas since that would be bit off.
Actually I take it back. Thinking more into it, yes, it think it would be good if returns the canvas object.
@aashish24 yes I think so too, otherwise all the canvas are created and not reachable easily any longer.
import vcs
vcs.createboxfill().plot(data).plot(data,vcs.createisoline())
Currently we can plot data using
plot
andboxfill()
calls. I would prefer we just have one method for plotting unless there is a strong need for another method. Thoughts?