RE: ISSUE-201: Aligning the two change proposals

I can live with unbacked region descriptions; I think that there are some valid use cases where the canvas author will have a very large number of hit regions that don't all need a full-fledged element. (Detailed maps, scatterplots, etc)

-----Original Message-----
From: Edward O'Connor [] 
Sent: Friday, June 29, 2012 3:03 PM
Subject: Re: ISSUE-201: Aligning the two change proposals

Hi all,

I wrote:

> Frank and I got together today and went through the remaining
> ISSUE-201 items.

I've made a pass at updating my Change Proposal to reflect what came out of that meeting. The updated proposal is available here:

Please review this updated proposal and let me know if I missed anything. Here's the diff from the previous version of the proposal:

>> [Frank's CP only] A method ( clearElementPath() ) to remove hit 
>> regions. I think we should have this in the joint proposal, as 
>> relying on ClearRect or other drawing mechanisms to clear an 
>> association seems overly involved and a burden on the author.
> We both agreed that having a clearElementPath() method makes sense.

To keep the method names aligned, I've added removeHitRegion() to my proposal.

>> r7025 - Add ellipse support to canvas. not needed, not accessibility
> Agreed; can wait.
>> r7026 - Add SVG paths to Path objects in canvas.
> Agreed, can wait.

I removed these revisions from the list of revisions to restore.

>> r7028 - add dashed lines and change how Path objects work to instead 
>> use external line and font styles and transformation objects
> I need to look at this in more detail to see if the refactoring is 
> necessary to make Path sufficiently useful.

I think leaving this in is probably necessary to keep the Path definition sane.

>> r7033 - More font metrics.
> Definitely helps wit hit testing runs of text, so I'd prefer to keep 
> this in. That said, I can live with putting it off until
>> r7034 - Path copy constructor
> I don't see the harm in keeping it, but like the font metrics, I can 
> live with putting it off as well.

I removed these revisions from the list of revisions to restore.

Rich wrote, in <>:

> Does this mean that the ligtweight JSON objects will be an 
> discussion item?

Sorry, I failed to mention unbacked region descriptions in my summary email of the conversation I had with Frank. I argued for keeping them in this version of the feature. I think Frank could live with that, but I don't want to put words in his mouth. Frank, what do you think? I haven't changed this aspect of my proposal.


Received on Thursday, 5 July 2012 22:40:40 UTC