Thanks
-Sean
Yes, I suspect this is a known bug that occurs when you have a root
panel with multiple data elements. (In this case, multiple SVG
elements are generated.) I've implemented a fix for the next version
(3.2) in development. You can try a pre-release version if you don't
mind building it yourself: http://gitorious.com/protovis
Mike
-Sean
> --
> You received this message because you are subscribed to the Google Groups "protovis" group.
> To post to this group, send email to prot...@googlegroups.com.
> To unsubscribe from this group, send email to protovis+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/protovis?hl=en.
>
>
Events aren't broken in 3.2, but there are other changes afoot that
may affect you.
Without being able to look at your example or the error messages in
more detail, I won't be able to say what the cause is. If you can,
send a link or attach a test case (or your example). Otherwise, use
the -d3.2js and tell me what the error message and stack trace are.
Thanks,
Mike
(new Date(2000, panel.i() * 3, 1)).format is not a function
It comes from the .text call that fills the label below each plot.
Interestingly, if I remove that call, the dot works as expected, but
the currently moused over plot disappears(or maybe it's just turning
white instead of green). Changing the "#2ca02c" to pv.rgb(0, 125, 0)
in the Area's fillStyle fixes that.
Thanks,
-Sean
One of the improvements in 3.2 is to no longer extend from built-in
JavaScript classes. So Date.format and Date.parse have been replaced
with a pv.Format.date class. (There's another pv.Format.time, too, for
durations.) You can replace the code with:
pv.Format.date("%B %Y")(new Date(2000, panel.i() * 3, 1))
> Changing the "#2ca02c" to pv.rgb(0, 125, 0) in the Area's fillStyle fixes that.
Woot, you found a bug. In 3.2, properties have explicit types. So,
when the fillStyle property is evaluated, Protovis knows it is a
color, and so you can depend on it being a color (which is nice if you
want to compute derivative colors using brighter/darker/alpha).
However, this particular example is using a def to define the
fillStyle property. In this case, the computed value was not
automatically being converted to a pv.color, so you'll need to do it
by hand (e.g., pv.color("#2ca02c")). I'll fix this and make sure that
defs go through the appropriate type conversion on render.
Mike
This bug has now been fixed, if you grab the latest from Gitorious.
Cheers,
Mike
Awesome, will do. Also, me re-rendering problem is gone.
Thanks again,
-sean
On Feb 19, 2010 5:04 PM, "Mike Bostock" <mbos...@cs.stanford.edu> wrote:
>> Changing the "#2ca02c" to pv.rgb(0, 125, 0) in the Area's fillStyle fixes that.
>
> Woot, you fou...
This bug has now been fixed, if you grab the latest from Gitorious.
Cheers,
Mike
--
You received this message because you are subscribed to the Google Groups "protovis" group...
Is the latest code not in googlecode's svn anymore? I've seen lots of
activity in http://gitorious.org/protovis, but not announced. Is this
official?
-pedro
Yes. It has not been announced because we want to let the code "bake"
somewhat before we make an official release. There are still a number
of features under development. If you are interested in testing out a
pre-release version and giving feedback, please clone the repo or
download the tarball!
Mike
Yes. It has not been announced because we want to let the code "bake"
somewhat before we make an official release. There are still a number
of features under development. If you are interested in testing out a
pre-release version and giving feedback, please clone the repo or
download the tarball!
After some hair-pulling, John and I have succeeded in importing the
full SVN history into Gitorious!
My apologies to those of you that already have a local clone of the
repo; you will need to recover from our upstream rebase. You can
either re-clone the repo, or follow John's instructions below.
Mike
-- begin git help --
If you didn't actually have any local commits beyond what's currently
pushed to origin/master, you can use the following command to reset:
git checkout master
git reset --hard origin/master
If you did have local commits, you can rebase them onto origin/master.
This is typically just:
git checkout master
git rebase origin/master
In this case git might get confused and try to merge identical
commits. If this happens, back out:
git rebase --abort
And then do an interactive rebase:
git rebase -i origin/master
Your editor will come up with a list of potential commits to be
rebased. For any duplicate commits already in origin/master, delete
those lines. Then save and exit the editor. Git rebase will run, but
skip the commits you deleted.
For more information, see the "RECOVERING FROM UPSTREAM REBASE" section here:
var vis = new pv.Panel()
.data(minnesota)
.....
var panel = vis.add(pv.Panel)
.......
var dot = panel.add(pv.Dot) //What do I refer to?
......
I have code later in my vis that catches mouse events and calls
dot.render(). When I do that only the dot instance from the panel I
am currently mousing over seems to receive the render call. What
magic is happening to make the target of my dot.render() call always
change?
panel.add(pv.Bar)
.event("mouseout", function() {
panel.i(-1);
vis.i(-1);
dot.render();
label.render();})
You have a Mark, which is a description of a set of related visual
elements. So the simple answer is that the `dot` refers to all
instances. Behind-the-scenes (no pun intended), this corresponds to a
hierarchical expansion from marks to visual items, also known as nodes
in the scene graph. The items are referenced in the `scene` property:
http://protovis-js.googlecode.com/svn/trunk/jsdoc/symbols/pv.Mark.html#scene
Consider the simple case of a lone Dot:
vis.add(pv.Dot)
...
If this dot were hypothetically rendered, since it lacks a data
property the default would be used, and a single Dot visual item would
be displayed. So after the render, dot.scene is a 1-element array. Now
consider a Dot with a data property:
vis.add(pv.Dot)
.data(pv.range(5))
...
When this dot is rendered, it's `scene` array would contain 5
elements, one per visual item. But what happens when both a Dot and
its parent Panel are multiplied?
vis.add(pv.Panel)
.data(pv.range(n))
.add(pv.Dot)
.data(pv.range(m))
...
We now have n*m dots. The hierarchy is stored on the panel's `scene`
attribute: panel.scene contains n elements. Each of those n elements
corresponds to a visual instantiation of the panel (along with the
panel's computed properties, like left and top). Each of those n
elements has a `children` attribute, which in this case is a 1-element
array since the panel only has one children. And those in turn
reference the dot's scene, an m-element array of the rendered Dots.
As marks are being rendered, Protovis internally sets and unsets the
`scene` attribute on each Mark so that it points to the correct place
in the hierarchy. The `index` property similar gets set to the current
instance. So in the above example, if we are rendering the ith panel,
then panel.index == i, and dot.scene == panel.scene[i].children[0].
> What magic is happening to make the target of my dot.render() call always
> change?
When event handlers are triggered, Protovis knows which instance of
the given mark (which visual item) triggered the event. It
correspondingly sets up the `scene` and `index` attributes for the
hierarchy before invoking the event handler. When render is called,
render checks to see if the `scene` and `index` attributes are set; if
they are, only those specific instances are rendered. Otherwise, if
render is called from a global context, Protovis will render all
instances of the given mark.
Mike