canviz - Project Hosting on Google Code

Older Aug 26, 2009 issue 11 (Support clickable nodes and edges) commented on by ryandesign.com - I filed issue #56 to explore a new idea for handling mouse events: use an image map. I filed issue #56 to explore a new idea for handling mouse events: use an image map. Aug 26, 2009 issue 56 (Use an image map to support clickable nodes and edges) reported by ryandesign.com - A new idea about how to handle clickability is to have Canviz request from the server not just the xdot representation but also the cmapx representation of the graph, both encapsulated into a JSON request. The image map is inserted into the document, and so is a transparent spacer gif which lies over the canvas. The image map is attached to the transparent spacer image. A test of this method can be checked out from the repository here: http://code.google.com/p/canviz/source/browse/test/gvimagemap/ This work should probably be done in a branch as there will be several steps. There will need to be code that re-computes the values in the image map when the scale of the graph is changed. It may be desirable for the server to transform the raw cmapx (and possibly the xdot too) into a proper JSON representation rather than just putting the two raw formats into a JSON wrapper. This should reduce the amount of data that has to be sent over the wire. Issue #11 was originally filed to support clicking, but the method focused on implementing hit detection code in the Path library in JavaScript. The problem is that in the xdot draw commands, Graphviz tells us how to draw the shape, but does not tell us its outline. For simple shapes like ovals these are the same, but for complex shapes they are not. Additionally, there is no information at all about clickable regions, of which there might be several if HTML-like labels are in use. A new idea about how to handle clickability is to have Canviz request from the server not just the xdot representation but also the cmapx representation of the graph, both encapsulated into a JSON request. The image map is inserted into the document, and so is a transparent spacer gif which lies over the canvas. The image map is attached to the transparent spacer image. A test of this method can be checked out from the repository here: http://code.google.com/p/canviz/source/browse/test/gvimagemap/ This work should probably be done in a branch as there will be several steps. There will need to be code that re-computes the values in the image map when the scale of the graph is changed. It may be desirable for the server to transform the raw cmapx (and possibly the xdot too) into a proper JSON representation rather than just putting the two raw formats into a JSON wrapper. This should reduce the amount of data that has to be sent over the wire. Issue #11 was originally filed to support clicking, but the method focused on implementing hit detection code in the Path library in JavaScript. The problem is that in the xdot draw commands, Graphviz tells us how to draw the shape, but does not tell us its outline. For simple shapes like ovals these are the same, but for complex shapes they are not. Additionally, there is no information at all about clickable regions, of which there might be several if HTML-like labels are in use. Aug 26, 2009 HowToUse (How to use Canviz) Wiki page commented on by pawan.gandhi - Hee Hee Aug 18, 2009 r284 (gvimagemap/index.php: Put the status display behind the imag...) committed by ryandesign.com - gvimagemap/index.php: Put the status display behind the image map. gvimagemap/index.php: Put the status display behind the image map. Aug 18, 2009 r283 (gvimagemap/styles.css: Remove unnecessary z-index properties...) committed by ryandesign.com - gvimagemap/styles.css: Remove unnecessary z-index properties. gvimagemap/styles.css: Remove unnecessary z-index properties. Aug 18, 2009 r282 (gvimagemap/styles.css: Use fixed instead of absolute positio...) committed by ryandesign.com - gvimagemap/styles.css: Use fixed instead of absolute position for the status box so it can't get scrolled away. gvimagemap/styles.css: Use fixed instead of absolute position for the status box so it can't get scrolled away. Aug 18, 2009 issue 55 (Support for encoded text values) changed by ryandesign.com - Labels in Graphviz are not defined as being URL-encoded values, so it doesn't make sense for Canviz to treat them as such. If you want to do so, you're welcome to keep this modification in your local copy of Canviz, but I won't make that change to the official version. I encourage you to discuss your UTF-8 difficulties in more detail with the developers of Graphviz on the graphviz-interest mailing list; perhaps they will have a solution. Another workaround for the issue that wouldn't involve modifying Canviz could be to use files instead of stdin and stdout. Status: WontFix Labels: Type-Enhancement −Type-Defect Labels in Graphviz are not defined as being URL-encoded values, so it doesn't make sense for Canviz to treat them as such. If you want to do so, you're welcome to keep this modification in your local copy of Canviz, but I won't make that change to the official version. I encourage you to discuss your UTF-8 difficulties in more detail with the developers of Graphviz on the graphviz-interest mailing list; perhaps they will have a solution. Another workaround for the issue that wouldn't involve modifying Canviz could be to use files instead of stdin and stdout. Status: WontFix Labels: Type-Enhancement −Type-Defect Aug 18, 2009 r281 (gvimagemap/index.php: Don't use base href tag because it doe...) committed by ryandesign.com - gvimagemap/index.php: Don't use base href tag because it doesn't work with Firefox here for some reason. gvimagemap/index.php: Don't use base href tag because it doesn't work with Firefox here for some reason. Aug 18, 2009 r280 (gvimagemap: Add example exercising the cmapx output from Gra...) committed by ryandesign.com - gvimagemap: Add example exercising the cmapx output from Graphviz. gvimagemap: Add example exercising the cmapx output from Graphviz. Aug 18, 2009 r279 (jsimagemap/README.txt: Refine wording. ) committed by ryandesign.com - jsimagemap/README.txt: Refine wording. jsimagemap/README.txt: Refine wording. Aug 18, 2009 r278 (jsimagemap: Add example showing how a client-side image map ...) committed by ryandesign.com - jsimagemap: Add example showing how a client-side image map can be created completely in JavaScript. jsimagemap: Add example showing how a client-side image map can be created completely in JavaScript. Aug 18, 2009 r277 (test: New directory. ) committed by ryandesign.com - test: New directory. test: New directory. Aug 14, 2009 issue 55 (Support for encoded text values) reported by rostislav.hristov - I'm having problems making graphviz work correctly with UTF-8 when using stdin and stdout. Because of that I ended up using URL encoded values and had to tweak canviz.js to decode them. Is it possible to have such decoding enabled in the library? canviz.js r265 line 224: text.update(decodeURI(str)); It seems that such a change won't break anything. I'm having problems making graphviz work correctly with UTF-8 when using stdin and stdout. Because of that I ended up using URL encoded values and had to tweak canviz.js to decode them. Is it possible to have such decoding enabled in the library? canviz.js r265 line 224: text.update(decodeURI(str)); It seems that such a change won't break anything. May 27, 2009 r276 (LICENSE.txt: Update year in copyright notice. ) committed by ryandesign.com - LICENSE.txt: Update year in copyright notice. LICENSE.txt: Update year in copyright notice. May 27, 2009 r275 (LICENSE.txt: Update year in copyright notice. ) committed by ryandesign.com - LICENSE.txt: Update year in copyright notice. LICENSE.txt: Update year in copyright notice. May 23, 2009 r274 (path.js: KAPPA should be a constant in the Ellipse class, no...) committed by ryandesign.com - path.js: KAPPA should be a constant in the Ellipse class, not an instance variable in each Ellipse object. path.js: KAPPA should be a constant in the Ellipse class, not an instance variable in each Ellipse object. May 23, 2009 issue 53 (Path should have a draw() method that actually draws the pat...) Status changed by ryandesign.com - firstDistance and drawFirst have not been dealt with, but I can add those later if necessary. Status: Fixed firstDistance and drawFirst have not been dealt with, but I can add those later if necessary. Status: Fixed May 23, 2009 r273 (example3.html: Add some translucency, why not. ) committed by ryandesign.com - example3.html: Add some translucency, why not. example3.html: Add some translucency, why not. May 23, 2009 r272 (example3.html: New example showing canvas transforms. ) committed by ryandesign.com - example3.html: New example showing canvas transforms. example3.html: New example showing canvas transforms. May 23, 2009 r271 (example2.html: Give the square dashed lines. ) committed by ryandesign.com - example2.html: Give the square dashed lines. example2.html: Give the square dashed lines. May 23, 2009 r270 (example2.html: New example showing how to draw shapes with t...) committed by ryandesign.com - example2.html: New example showing how to draw shapes with the new draw() method. example2.html: New example showing how to draw shapes with the new draw() method. May 23, 2009 issue 53 (Path should have a draw() method that actually draws the pat...) Status changed by ryandesign.com - r269: Path now has a draw() method that actually draws. Path constructors now take an optional argument options, where you can specify anything that could apply to a context, and also the "x_" options that are unique to Path: * x_fill (do you want it filled? default: false) * x_stroke (do you want it stroked? default: true) * x_strokeType ('solid' (default), 'dashed' or 'dotted') * x_dashLength (for dashed strokes; default: 6, measured in pixels) * x_dotSpacing (for dotted strokes; default: 4, measured in pixels) The defaults for dash length and dot spacing may change. I opted not to do anything clever, so if you want a Path filled, you do have to set both x_fill and (unless you want black) fillStyle. Status: Started r269: Path now has a draw() method that actually draws. Path constructors now take an optional argument options, where you can specify anything that could apply to a context, and also the "x_" options that are unique to Path: * x_fill (do you want it filled? default: false) * x_stroke (do you want it stroked? default: true) * x_strokeType ('solid' (default), 'dashed' or 'dotted') * x_dashLength (for dashed strokes; default: 6, measured in pixels) * x_dotSpacing (for dotted strokes; default: 4, measured in pixels) The defaults for dash length and dot spacing may change. I opted not to do anything clever, so if you want a Path filled, you do have to set both x_fill and (unless you want black) fillStyle. Status: Started May 23, 2009 r269 (path.js: Give a Path the ability to draw() itself. Path init...) committed by ryandesign.com - path.js: Give a Path the ability to draw() itself. Path initialization methods get a new options parameter for specifying context and other attributes to apply to this Path. See issue #53 . path.js: Give a Path the ability to draw() itself. Path initialization methods get a new options parameter for specifying context and other attributes to apply to this Path. See issue #53 . May 19, 2009 r268 (path.js: Add offset() methods to the Polygon, Rect and Ellip...) committed by ryandesign.com - path.js: Add offset() methods to the Polygon, Rect and Ellipse classes so the instance variables are offset too, not just the segments. path.js: Add offset() methods to the Polygon, Rect and Ellipse classes so the instance variables are offset too, not just the segments. May 19, 2009 r267 (path.js: "return this" from the offset() method in Point and...) committed by ryandesign.com - path.js: "return this" from the offset() method in Point and Bezier so that you can chain this method with others. path.js: "return this" from the offset() method in Point and Bezier so that you can chain this method with others. May 19, 2009 r266 (path.js: Always use Object.inUndefined(), for consistency, i...) committed by ryandesign.com - path.js: Always use Object.inUndefined(), for consistency, instead of checking typeof ourselves. path.js: Always use Object.inUndefined(), for consistency, instead of checking typeof ourselves. May 19, 2009 issue 53 (Path should have a draw() method that actually draws the pat...) commented on by ryandesign.com - r265: Updated Canviz to take these changes into account. r265: Updated Canviz to take these changes into account. May 19, 2009 r265 (Canviz: Update externals to use latest Path library; see iss...) committed by ryandesign.com - Canviz: Update externals to use latest Path library; see issue #53 . canviz.js: Update for renamed methods. Canviz: Update externals to use latest Path library; see issue #53 . canviz.js: Update for renamed methods. May 19, 2009 r264 (Path examples: Use peg revisions to lock down externals defi...) committed by ryandesign.com - Path examples: Use peg revisions to lock down externals definitions even if the paths they reference move or disappear in the future. Path examples: Use peg revisions to lock down externals definitions even if the paths they reference move or disappear in the future. May 19, 2009 r263 (Use peg revisions to lock down externals definitions even if...) committed by ryandesign.com - Use peg revisions to lock down externals definitions even if the paths they reference move or disappear in the future. Use peg revisions to lock down externals definitions even if the paths they reference move or disappear in the future. May 19, 2009 issue 54 (Support mouseenter and mouseleave events) reported by ryandesign.com - Once Prototype 1.6.1 is released and I import it into the Canviz repository and update Canviz and Path to use it, I can add support for mouseenter and mouseleave events. Once Prototype 1.6.1 is released and I import it into the Canviz repository and update Canviz and Path to use it, I can add support for mouseenter and mouseleave events. May 19, 2009 issue 53 (Path should have a draw() method that actually draws the pat...) commented on by ryandesign.com - r262: Renamed draw => makePath, drawDotted => makeDottedPath, drawDashed => makeDashedPath, drawCommands => pathCommands. r262: Renamed draw => makePath, drawDotted => makeDottedPath, drawDashed => makeDashedPath, drawCommands => pathCommands. May 19, 2009 r262 (path.js: Rename draw => makePath, drawDotted => makeDottedPa...) committed by ryandesign.com - path.js: Rename draw => makePath, drawDotted => makeDottedPath, drawDashed => makeDashedPath, drawCommands => pathCommands. See issue #53 . example1.html: Make corresponding changes. path.js: Rename draw => makePath, drawDotted => makeDottedPath, drawDashed => makeDashedPath, drawCommands => pathCommands. See issue #53 . example1.html: Make corresponding changes. May 19, 2009 issue 53 (Path should have a draw() method that actually draws the pat...) reported by ryandesign.com - Currently, Path has a draw() method that merely constructs the path on the canvas context, and it's still up to the user of Path to beginPath() before and fill() and/or stroke() after. The existing draw() (and drawDashed() and drawDotted()) methods should be renamed to something better matching their purpose. Then a new draw() method should be created which actually draws (fills and/or strokes) the path. The drawPath() method in Canviz could be the starting point for Path's new draw() method. The Path class will need to gain a place to store the context attributes that are important to it, such as stroke style (color string or gradient or pattern); fill style; line width; line cap; etc. This could be implemented as a settings object which directly maps to variables in the context (e.g. strokeStyle, fillStyle, lineWidth, lineCap). Path could further infer that if you set strokeStyle, you would like the path to be stroked, and if you set fillStyle, you would like the path to be filled. That leaves the parameters for dashed and dotted lines, for which there are no context variable since this feature is unique to Path. The needed parameters include whether to draw solid, dashed or dotted lines; the dash or dot spacing; the distance to the first dot or dash ("firstDistance"), and (for dashed lines) whether the first section of line is drawn or skipped ("drawFirst"). The latter two would be optional and would probably not be used much in practice (they aren't used by Canviz), but Path does need to keep track of them for properly drawing paths composed of multiple segments, and example 1 sets them directly to animate the dashed and dotted lines. These custom properties could also be stored in the same settings object but with special names that Path knows to look for and handle itself. Possibly these keys should be prefixed with "x" or "x_" to indicate they are eXperimental and not part of the spec. Currently, Path has a draw() method that merely constructs the path on the canvas context, and it's still up to the user of Path to beginPath() before and fill() and/or stroke() after. The existing draw() (and drawDashed() and drawDotted()) methods should be renamed to something better matching their purpose. Then a new draw() method should be created which actually draws (fills and/or strokes) the path. The drawPath() method in Canviz could be the starting point for Path's new draw() method. The Path class will need to gain a place to store the context attributes that are important to it, such as stroke style (color string or gradient or pattern); fill style; line width; line cap; etc. This could be implemented as a settings object which directly maps to variables in the context (e.g. strokeStyle, fillStyle, lineWidth, lineCap). Path could further infer that if you set strokeStyle, you would like the path to be stroked, and if you set fillStyle, you would like the path to be filled. That leaves the parameters for dashed and dotted lines, for which there are no context variable since this feature is unique to Path. The needed parameters include whether to draw solid, dashed or dotted lines; the dash or dot spacing; the distance to the first dot or dash ("firstDistance"), and (for dashed lines) whether the first section of line is drawn or skipped ("drawFirst"). The latter two would be optional and would probably not be used much in practice (they aren't used by Canviz), but Path does need to keep track of them for properly drawing paths composed of multiple segments, and example 1 sets them directly to animate the dashed and dotted lines. These custom properties could also be stored in the same settings object but with special names that Path knows to look for and handle itself. Possibly these keys should be prefixed with "x" or "x_" to indicate they are eXperimental and not part of the spec. May 19, 2009 issue 43 (Use Silverlight version of excanvas if possible) commented on by ryandesign.com - ExplorerCanvas release 3 is out, and it does not contain the Silverlight version. When asked about this on the mailing list, the developers said this is because of some outstanding issues with the Silverlight script, and that they plan to merge the Silverlight and VML versions into a single script. So for Canviz we may not have to do anything but wait for this to happen. http://groups.google.com/group/google-excanvas/browse_thread/thread/e2d9dc2ee5880912 ExplorerCanvas release 3 is out, and it does not contain the Silverlight version. When asked about this on the mailing list, the developers said this is because of some outstanding issues with the Silverlight script, and that they plan to merge the Silverlight and VML versions into a single script. So for Canviz we may not have to do anything but wait for this to happen. http://groups.google.com/group/google-excanvas/browse_thread/thread/e2d9dc2ee5880912 May 19, 2009 r261 (path.js: Rect is now based on Polygon. ) committed by ryandesign.com - path.js: Rect is now based on Polygon. path.js: Rect is now based on Polygon. May 19, 2009 r260 (path.js: New class Polygon. ) committed by ryandesign.com - path.js: New class Polygon. path.js: New class Polygon. Jan 26, 2009 issue 52 (add json capability to load()) Status changed by ryandesign.com - We talked about this in the discussion group: http://groups.google.com/group/canviz/browse_thread/thread/3ce5e24c272f3191 I suggested we not add this to Canviz, because it's hard to anticipate the needs of every Canviz client. Instead, Canviz will continue to provide its simple load() method, and if you need more complicated loading, do it yourself in your own code, and then call your Canviz object's parse() method and give it the xdot code you've loaded. See the above thread for sample code. Status: WontFix We talked about this in the discussion group: http://groups.google.com/group/canviz/browse_thread/thread/3ce5e24c272f3191 I suggested we not add this to Canviz, because it's hard to anticipate the needs of every Canviz client. Instead, Canviz will continue to provide its simple load() method, and if you need more complicated loading, do it yourself in your own code, and then call your Canviz object's parse() method and give it the xdot code you've loaded. See the above thread for sample code. Status: WontFix Jan 26, 2009 issue 11 (Support clickable nodes and edges) commented on by ryandesign.com - I can ask Prototype to fire an event if necessary. But let's let this issue be for the feature of making the node/edge shapes clickable. If you find you need an onload event fired later, we can address that in another ticket. I can ask Prototype to fire an event if necessary. But let's let this issue be for the feature of making the node/edge shapes clickable. If you find you need an onload event fired later, we can address that in another ticket. Jan 20, 2009 issue 47 (Makefile not compatible with GNU xargs) commented on by ryandesign.com - Thanks, done in r259. The problem is it doesn't fix the issue for Ron, whose GNU xargs is too old to have the -I option. I'm thinking of forgoing xargs and using a for loop instead. Thoughts? Other ideas? Thanks, done in r259. The problem is it doesn't fix the issue for Ron, whose GNU xargs is too old to have the -I option. I'm thinking of forgoing xargs and using a for loop instead. Thoughts? Other ideas? Jan 20, 2009 r259 (Makefile: Use -I instead of -J for compatibility with GNU xa...) committed by ryandesign.com - Makefile: Use -I instead of -J for compatibility with GNU xargs. See issue #47. Makefile: Use -I instead of -J for compatibility with GNU xargs. See issue #47. Jan 19, 2009 issue 47 (Makefile not compatible with GNU xargs) commented on by mrkvnz - On gnu systems use -I $ svn diff Makefile Index: Makefile =================================================================== --- Makefile (revision 258) +++ Makefile (working copy) @@ -75,7 +76,7 @@ endef examples-images: $(EXAMPLE_GRAPH_IMAGES_DIR) - $(FIND) $(EXAMPLE_GRAPHS_SRC_DIR) -type f -name '.gif' -or -name '.jpg' -or -name '.png' -print0 \| $(XARGS) -0 -t -n 1 -J % cp % $(EXAMPLE_GRAPH_IMAGES_DIR) + $(FIND) $(EXAMPLE_GRAPHS_SRC_DIR) -type f -name '.gif' -or -name '.jpg' -or -name '.png' -print0 \| $(XARGS) -0 -t -n 1 -I % cp % $(EXAMPLE_GRAPH_IMAGES_DIR) On gnu systems use -I $ svn diff Makefile Index: Makefile =================================================================== --- Makefile (revision 258) +++ Makefile (working copy) @@ -75,7 +76,7 @@ endef examples-images: $(EXAMPLE_GRAPH_IMAGES_DIR) - $(FIND) $(EXAMPLE_GRAPHS_SRC_DIR) -type f -name '.gif' -or -name '.jpg' -or -name '.png' -print0 \| $(XARGS) -0 -t -n 1 -J % cp % $(EXAMPLE_GRAPH_IMAGES_DIR) + $(FIND) $(EXAMPLE_GRAPHS_SRC_DIR) -type f -name '.gif' -or -name '.jpg' -or -name '.png' -print0 \| $(XARGS) -0 -t -n 1 -I % cp % $(EXAMPLE_GRAPH_IMAGES_DIR) Jan 16, 2009 FAQ (Frequently-asked questions.) Wiki page edited by ryandesign.com Jan 11, 2009 issue 52 (add json capability to load()) Labels changed by ryandesign.com - Labels: Type-Enhancement −Type-Defect Labels: Type-Enhancement −Type-Defect Jan 11, 2009 issue 52 (add json capability to load()) reported by ron.newman - What steps will reproduce the problem? Not a problem, but a requested enhancement. Oftentimes it is necessary to pass back from a server auxiliary data besides the xdot source: prompts, thumbnail data, etc. So I suggest that the load() method have an additional parameter: is_json. When true, canviz expects JSON data, and parses the xdot portion using of it Prototype, then calls a user javascript function outside of canviz for any postprocessing of the rest of the JSON data. Something like: // ******* this part unchanged *********** load: function(url, url_params,is_json) { $('debug_output').innerHTML = ''; new Ajax.Request(url, { method: 'get', parameters: url_params, onComplete: function(response) { // * changed part: ************ if(is_json) { this.json = response.responseText.evalJSON(true); this.parse(this.json.image); postproc_json(this.json); } else { this.parse(response.responseText); } // * end changed part ************* }.bind(this) }); }, and the user might have, outside of canviz.js, something like: function postproc_json(jsonresponse) { $('thumbnails').innerHTML = jsonresponse.thumbnails; $('refresh_prompt').innerHTML = jsonresponse.refresh_prompt; $('auxactions').innerHTML = jsonresponse.auxactions; // anything that requires a script to run AFTER the Ajax response is complete. eval($('auxactions').innerHTML); return(true); } What steps will reproduce the problem? Not a problem, but a requested enhancement. Oftentimes it is necessary to pass back from a server auxiliary data besides the xdot source: prompts, thumbnail data, etc. So I suggest that the load() method have an additional parameter: is_json. When true, canviz expects JSON data, and parses the xdot portion using of it Prototype, then calls a user javascript function outside of canviz for any postprocessing of the rest of the JSON data. Something like: // ***** this part unchanged *********** load: function(url, url_params,is_json) { $('debug_output').innerHTML = ''; new Ajax.Request(url, { method: 'get', parameters: url_params, onComplete: function(response) { // * changed part: ************ if(is_json) { this.json = response.responseText.evalJSON(true); this.parse(this.json.image); postproc_json(this.json); } else { this.parse(response.responseText); } // * end changed part *************** }.bind(this) }); }, and the user might have, outside of canviz.js, something like: function postproc_json(jsonresponse) { $('thumbnails').innerHTML = jsonresponse.thumbnails; $('refresh_prompt').innerHTML = jsonresponse.refresh_prompt; $('auxactions').innerHTML = jsonresponse.auxactions; // anything that requires a script to run AFTER the Ajax response is complete. eval($('auxactions').innerHTML); return(true); } Jan 09, 2009 issue 51 (Switch local variables to lowerCamelCase) commented on by ryandesign.com - r257: Fixed canviz.js to use lowerCamelCase r257: Fixed canviz.js to use lowerCamelCase Jan 09, 2009 r257 (canviz.js: Switch from underscore_separated_words to lowerCa...) committed by ryandesign.com - canviz.js: Switch from underscore_separated_words to lowerCamelCase for all function parameters and local variable names, to match path.js and prototype.js. See issue #51. canviz.js: Switch from underscore_separated_words to lowerCamelCase for all function parameters and local variable names, to match path.js and prototype.js. See issue #51. Jan 08, 2009 issue 11 (Support clickable nodes and edges) commented on by ron.newman - Re: comment 9, supporting mouse events, I propose that onload also be supported so that drag and drop can be done in Firefox. This is because standards-compliant browsers like Firefox will not notice an onmouseup event without having an event listener instantiated. And an onload allows you to instantiate individual listeners for each div, and what the div IDs are. This presupposes that onload fires when the DOM is updated by Prototype with new xdot data. Re: comment 9, supporting mouse events, I propose that onload also be supported so that drag and drop can be done in Firefox. This is because standards-compliant browsers like Firefox will not notice an onmouseup event without having an event listener instantiated. And an onload allows you to instantiate individual listeners for each div, and what the div IDs are. This presupposes that onload fires when the DOM is updated by Prototype with new xdot data. Jan 08, 2009 issue 49 (New example: how to switch to using Canviz) Status changed by ryandesign.com - r256: Added the new example. It exposes a problem in Canviz where the div has zero height... Need to investigate that. Status: Fixed r256: Added the new example. It exposes a problem in Canviz where the div has zero height... Need to investigate that. Status: Fixed Jan 08, 2009 r256 (New hello_world example. See issue #49. ) committed by ryandesign.com - New hello_world example. See issue #49 . New hello_world example. See issue #49 .

issue 53 (Path should have a draw() method that actually draws the pat...) reported by ryandesign.com - Currently, Path has a draw() method that merely constructs the path on the canvas context, and it's still up to the user of Path to beginPath() before and fill() and/or stroke() after. The existing draw() (and drawDashed() and drawDotted()) methods should be renamed to something better matching their purpose. Then a new draw() method should be created which actually draws (fills and/or strokes) the path. The drawPath() method in Canviz could be the starting point for Path's new draw() method. The Path class will need to gain a place to store the context attributes that are important to it, such as stroke style (color string or gradient or pattern); fill style; line width; line cap; etc. This could be implemented as a settings object which directly maps to variables in the context (e.g. strokeStyle, fillStyle, lineWidth, lineCap). Path could further infer that if you set strokeStyle, you would like the path to be stroked, and if you set fillStyle, you would like the path to be filled. That leaves the parameters for dashed and dotted lines, for which there are no context variable since this feature is unique to Path. The needed parameters include whether to draw solid, dashed or dotted lines; the dash or dot spacing; the distance to the first dot or dash ("firstDistance"), and (for dashed lines) whether the first section of line is drawn or skipped ("drawFirst"). The latter two would be optional and would probably not be used much in practice (they aren't used by Canviz), but Path does need to keep track of them for properly drawing paths composed of multiple segments, and example 1 sets them directly to animate the dashed and dotted lines. These custom properties could also be stored in the same settings object but with special names that Path knows to look for and handle itself. Possibly these keys should be prefixed with "x" or "x_" to indicate they are eXperimental and not part of the spec.

Currently, Path has a draw() method that merely constructs the path on the canvas context, and it's still up to the user of Path to beginPath() before and fill() and/or stroke() after. The existing draw() (and drawDashed() and drawDotted()) methods should be renamed to something better matching their purpose. Then a new draw() method should be created which actually draws (fills and/or strokes) the path. The drawPath() method in Canviz could be the starting point for Path's new draw() method. The Path class will need to gain a place to store the context attributes that are important to it, such as stroke style (color string or gradient or pattern); fill style; line width; line cap; etc. This could be implemented as a settings object which directly maps to variables in the context (e.g. strokeStyle, fillStyle, lineWidth, lineCap). Path could further infer that if you set strokeStyle, you would like the path to be stroked, and if you set fillStyle, you would like the path to be filled. That leaves the parameters for dashed and dotted lines, for which there are no context variable since this feature is unique to Path. The needed parameters include whether to draw solid, dashed or dotted lines; the dash or dot spacing; the distance to the first dot or dash ("firstDistance"), and (for dashed lines) whether the first section of line is drawn or skipped ("drawFirst"). The latter two would be optional and would probably not be used much in practice (they aren't used by Canviz), but Path does need to keep track of them for properly drawing paths composed of multiple segments, and example 1 sets them directly to animate the dashed and dotted lines. These custom properties could also be stored in the same settings object but with special names that Path knows to look for and handle itself. Possibly these keys should be prefixed with "x" or "x_" to indicate they are eXperimental and not part of the spec.

Older