[dojo-contributors] Re: Draft: Unified 2D graphics subsystem for Dojo

Eugene Lazutkin eugene at lazutkin.com
Mon Jun 5 21:26:40 EDT 2006


Tom Trenka wrote:
> 
> Before I go any further on the commentary, I think it's important to 
> reiterate something that came about at the Dojo Dev Day, in discussions 
> with Dylan, myself and Jon Ferraiolo (one of the prime movers behind 
> both the SVG spec and the Adobe SVG Viewer, now at IBM); we're going to 
> take a different approach with respect to VML handling, by creating an 
> XSL stylesheet that will attempt to translate SVG to VML, so that this 
> is transparent, thereby eliminating (hopefully) any need to deal with 
> cross-browser issues (cough IE cough).  As soon as I get a chance 
> (probably this week), I'll be starting the work on it, with the really 
> hopeful goal that it makes it to 0.4 (probably be more like 0.5 but 
> we'll see).

Cool. Let me point out that it is impossible to emulate SVG with VML 
with 100% accuracy. The other thing is DOM support should be handled as 
well. You may spend more time parsing the resulting VML and mapping it 
back to the original SVG DOM than using a specialized API.

>     Sorry for leaving whys out.
> 
> No worries--I personally have a good idea of your why but I think we 
> need to be explicit, since we are a group of developers with some pretty 
> diverse backgrounds.

I am 100% with you on that.

> I'm going to comment on all of this down below, but I'll point out here 
> quickly that the big issue with this API, with the reasoning you have 
> here, is that it places the widget definition usage back in the 
> procedural domain (as opposed to declarative), which is somewhat 
> contrary to the Dojo approach.  Not that I disagree with your sentiment 
> here at all, but I think it's something that needs to be pointed out.

I did comment on it in my original proposal at the very bottom in 
section "Unified markup language". I dislike procedural approach myself 
but we have to have some code actually creating some DOM nodes and 
producing a picture. In the proposal I offered two solutions: a subset 
of SVG with possible augmentation (Gavin favors this approach), or a 
custom markup. I favor SVG too, but it is not a clear winner --- I need 
your input.

> While I don't disagree that interactive graphics are very important, I 
> would like to not have 3 different APIs competing for each other; we've 
> got your proposed spec, the one that the gentleman for XDraw is 
> proposing, and the approach we decided on at Dojo Dev Day.  I know that 

While I have no idea about DDD approach, I am in contact with Gavin. I 
want to unify all input under one roof. It's not about ownership, it's 
about a reasonable solution, which is easy to implement, and easy to use.

> the OpenLazslo guys are also wanting/looking for a drawing API--for some 
> of the same reasons you've described--and they were pretty keen on 
> having it follow the Canvas spec as best as possible.

Of course, with Canvas being the worst API in our stable it is not a 
good thing but I am open to suggestions.

> I'd also like to point out that starting with charts is probably not the 
> best way to go; charting solutions are among the most complex things we 
> can try to pull, and starting with the most difficult thing (IMHO) is a 
> really bad idea.  This is why I'm working on a Gauge widget right now, 
> as a test platform for pure SVG and VML support.

I don't want to start with "charts". I want to start with "a chart" --- 
in this case it is a pie chart. I don't think it is too complex. It has 
no axes, I am not going to do a legend (should be done by a different 
widget). It will have just graphics and simple labels --- did I miss 
something important?

> So...with that in mind, I'd *really* like to get a nice, big list of the 
> things we're really aiming to support *first*, and *then* start talking 
> about an API.  Let me start:
> 
> 1. Interactive flowcharts.
> 2. Interactive drawing tools.
> 3. More informative charting.
> 4. The ability to use an API like this to create much prettier widgets 
> (a la Apple's Dashboard).

You almost covered my wish list. :-) Anyway I am talking about low-level 
part, while you are talking about high-level functionality. I understand 
your point, but at the end of day we will have the same Canvas/SVG/VML. 
If they don't support something, we cannot do it efficiently. Not in 
JavaScript anyway.

> (btw, if you'd like to work together on the chart stuff offlist, I'd 
> love to talk; the current Chart widget supports a lot more than you'd 
> probably expect, and I have some definite ideas on where it's 
> going...including support for pie charts, radar/polar charts, log 
> charts, and 3d contour/surface plots).

I am all for it. BTW, do you have *real* use cases for these widgets? 
For example, when I worked for certain oil and gas software company our 
customers wanted basemaps, 2D contours, seismics, welllogs, but nobody 
cared for radial/polar charts. It never came up in my experience.

> (Also, it *might* be possible to do event handling on canvas-drawn 
> images through the use of position detection, but I don't want to even 
> attempt that yet.)

Yes, I know --- I even know how to do that. :-) But I don't want to do 
it now. :-) Maybe later.

Thanks,

Eugene



More information about the dojo-contributors mailing list