[dojo-contributors] SVG/VML/Canvas API discussion

Tom Trenka ttrenka at gmail.com
Tue Apr 18 10:09:52 EDT 2006


That's the exact reason I'm putting the question out to the list: to figure
out the API.  On reflection (inside me head) I'm not even sure we need a
shim library; we might be able to offer a set of primitives as straight up
widgets.

At some point (hopefully today) I'll put together an example widget markup
and post it here, and then maybe a full-on discussion could ensue.  Perhaps
something like this?

<div dojoType="drawing">
    <div dojoType="circle"></div>
    <div dojoType="line"></div>
    <div dojoType="rectangle"></div>
</div>

In all honesty I think that this is probably possible now, without any
special shims.  Although (of course) we'd have to make it actually *work* =)

trt

On 4/18/06, Bill Keese <bill at dojotoolkit.org> wrote:
>
> Well, let's decide what API we want first, and then think about what
> implementations (canvas/svg/vml) we support.  Extending your example,
> can I do this?
>
> var line = dojo.draw.line(...);
> line.setOnClick( function(){ alert("hi!"); });
>
> (and then later on, line.destroy();)
>
> Bill
>
> Tom Trenka wrote:
> > It's not so much of whether we should or shouldn't support Canvas, per
> > se.  I know that some feel that canvas is very limited but I think
> > that's because it really is just a canvas upon which you can draw raster
> > primitives.  Both SVG and VML are vector languages (think the difference
> > between a JPG and an EPS file).
> >
> > But we'd start off script-based, and so the *commands* currently
> > implemented with canvas would probably be the best place to start--even
> > though underneath they'd be rendering to SVG or VML.  That's essentially
> > what I meant.  For instance, dojo.draw.line() would map to <svg:line />
> > and <vml:line />, etc.
> >
> > Anyways, that's the thought.
> >
> > trt
> >
> > On 4/17/06, *Bill Keese* < bill at dojotoolkit.org
> > <mailto:bill at dojotoolkit.org>> wrote:
> >
> >      > I know one of the things Alex has asked me for is that any
> primitive
> >      > drawn be able to fire and respond to events.  Not sure how we'll
> pull
> >      > that off with actual Canvas drawings, but I'll cross that bridge
> when
> >      > we get to it (probably it will involve looking for a mouse click
> on
> >      > the canvas element itself--if that's supported--and then
> >     analyzing the
> >      > current rendering to see what the top most element is that one
> >     clicked
> >      > on, what fun).
> >
> >     PS: I realized my last message wasn't clear.  What I meant was,
> >     maybe we
> >     shouldn't support Canvas.  If we just support SVG/VML then it's
> easier
> >     to support events.  I'm not sure of all the pros/cons though.
> >
> >     Bill
> >
> >     Bill Keese wrote:
> >      > Hi Tom,
> >      >
> >      > Thanks for handling this, and also for doing the bug triage.
> >      >
> >      > There's a guy named Gavin that promised to do this API but I
> haven't
> >      > heard anything from him for a while; maybe he lost
> >     interest.  Here's the
> >      > link:
> >      >
> >      > http://thread.gmane.org/gmane.comp.web.dojo.user/5504/focus=5726
> >      >
> >      > (this is why I made that InProgressProjects page on the wiki)
> >      >
> >      > As for my comments: I'm not a graphics expert, but I wonder
> >     whether we
> >      > should support the canvas API model (like you suggested) or the
> SVG
> >      > model.  The difference being that in SVG there's a handle to
> every
> >      > object you draw, so you can attach event handlers / erase
> previously
> >      > drawn objects, etc.  Presumably canvas is faster but SVG/VML are
> more
> >      > powerful.
> >      >
> >      > Bill
> >      >
> >      > Tom Trenka wrote:
> >      >> Hi all,
> >      >>
> >      >> Since the Iterator discussion went *so* well (&lt;sarcasm/&gt;
> >     but not
> >      >> really), I figure it's time to start asking questions about an
> >      >> SVG/VML/Canvas library, since it would seem that some think this
> >     would
> >      >> be a very useful thing.  So let me kick off the discussion
> >     (since I'll
> >      >> probably write it)...
> >      >>
> >      >> The nominal purpose of an SVG+VML+Canvas library would be to add
> a
> >      >> single layer of abstraction over the two vector (and one bitmap)
> >      >> drawing languages so that a developer can write one set of code,
> >     and
> >      >> have it render properly on the major browser
> platforms.  However, I
> >      >> have some issues with this, so let me lay this out first before
> >     diving
> >      >> into a request for purpose+proposal.
> >      >>
> >      >> 1.  My personal feeling is that widgets (one of the core uses
> for
> >      >> something like this) should not be limited to an encompassing
> >     API for
> >      >> drawing, and that there's no real difference (aside from
> platform)
> >      >> between writing markup in VML and SVG and writing markup in
> >     HTML.  All
> >      >> three are valid, existing markup languages; to force an API over
> two
> >      >> of these languages would be a detriment to the system.
> >      >>
> >      >> Note the use of the term "force".  I'm not suggesting the API
> isn't
> >      >> needed, just that we shouldn't force things to rely on it that
> we
> >      >> release ourselves.
> >      >>
> >      >> 2.  In the same vein, we shouldn't ignore the need for core
> files in
> >      >> the same vein as style.js and html.js for the other markup
> >     languages.
> >      >> svg.js is already a part of the library (even though a good
> >     portion of
> >      >> the functionality in that file is stub functionality that isn't
> >      >> working yet).  I might expect there to be a vml.js at some point
> as
> >      >> well; I will certainly add it when I get a better sense of what
> >     kind
> >      >> of helper functions are needed (particularly when we finally
> address
> >      >> DnD with vector markup).
> >      >> ---
> >      >> All of which to say is that I'd like it to be clear that any
> vector
> >      >> API could (and probably will) rely on some core files but it
> should
> >      >> not be the other way around.
> >      >>
> >      >> Now that that disclaimer is out of the way...what do we think we
> >     want
> >      >> out of such an API?  What kind of opinions are there as to the
> shape
> >      >> of such an API?  What does Dojo really need in these terms?
> >      >>
> >      >> I'll put forth a suggestion, and then let's discuss:  I would
> >     say that
> >      >> we would start with a script-based API, modeled on the Canvas
> API,
> >      >> upon which we could write general purpose widgets to represent
> >     drawing
> >      >> primitives (and eventually more complex ones).  Before anyone
> >     objects,
> >      >> let me try to be clear:  when I say "modeled" on the Canvas API,
> I'm
> >      >> referring to methods and the general results of those
> methods.  The
> >      >> Canvas API is based on OpenGL, which makes sense from a
> scripting
> >      >> standpoint; I don't see any reason why we shouldn't use the same
> >      >> approach.
> >      >>
> >      >> I know one of the things Alex has asked me for is that any
> >     primitive
> >      >> drawn be able to fire and respond to events.  Not sure how we'll
> >     pull
> >      >> that off with actual Canvas drawings, but I'll cross that bridge
> >     when
> >      >> we get to it (probably it will involve looking for a mouse click
> on
> >      >> the canvas element itself--if that's supported--and then
> >     analyzing the
> >      >> current rendering to see what the top most element is that one
> >     clicked
> >      >> on, what fun).  What other things would you want out of such an
> >     API?
> >      >>
> >      >> trt
> >      >>
> >      >> (for the record, I will certainly be looking at the Google
> >      >> ExplorerCanvas code but I'm pretty sure we won't incorporate it
> >      >> because of licensing...unless, Alex, you want to take a close
> >     look at
> >      >> it and see?  My inclination is to learn from it but not use it,
> just
> >      >> to be safe, plus I'd hate for Dojo to be reliant on other
> >      >> projects--since it seems like one of the goals here is to be the
> >     other
> >      >> way around).
> >      >>
> >      >>
> >      >>
> >
> ------------------------------------------------------------------------
> >      >>
> >      >> _______________________________________________
> >      >> dojo-contributors mailing list
> >      >> dojo-contributors at dojotoolkit.org
> >     <mailto:dojo-contributors at dojotoolkit.org>
> >      >> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
> >     <http://dojotoolkit.org/mailman/listinfo/dojo-contributors>
> >      > _______________________________________________
> >      > dojo-contributors mailing list
> >      > dojo-contributors at dojotoolkit.org
> >     <mailto:dojo-contributors at dojotoolkit.org>
> >      > http://dojotoolkit.org/mailman/listinfo/dojo-contributors
> >     _______________________________________________
> >     dojo-contributors mailing list
> >     dojo-contributors at dojotoolkit.org
> >     <mailto:dojo-contributors at dojotoolkit.org>
> >     http://dojotoolkit.org/mailman/listinfo/dojo-contributors
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > dojo-contributors mailing list
> > dojo-contributors at dojotoolkit.org
> > http://dojotoolkit.org/mailman/listinfo/dojo-contributors
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20060418/972600a1/attachment.htm 


More information about the dojo-contributors mailing list