[dojo-contributors] Re: Draft: Unified 2D graphics subsystem for Dojo
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
> 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
> 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
> (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.
More information about the dojo-contributors