Re: [PDX.rb] Scruffy Graphs

[Brasten Sager]

David- Plus, the graphs look great and I can probably use batik for my application. I'd love to see this in action if you end up going that route! I'd suggest taking the examples from your blog and putting them in the rdoc so it's easier for folks to find and get started.  The Rakefile rdoc section could even generate PNGs right from the examples!  Also, the render method could use some better examples.  There's a lot of docs that still need to be finished but I think just this little bit should help more folks adopt Scruffy early and get you some feedback. Good call on the examples.  The documentation is definitely thin, and not entirely accurate.  A lot had changed internally with the application in the last couple days that I haven't yet documented, including most of the really cool features, like custom layouts and such. The next couple evenings will be devoted to getting the docs up-to-date. What are the implications of making a whole bunch of little sparklines with Scruffy?  I noticed you internally work with a minimum graph size and scale down at raster time:       if options[:as] && (options[:size][0] <= 300 || options[:size][1] <= 200)         options[:actual_size] = options[:size]         options[:size] = [800, (800.to_f * (options[:actual_size][1].to_f / options[:actual_size][0].to_f))]         puts options[:size].inspect       end Also, does the case of requesting a 200x20 graph (a long sparkline) do what you want here?  It will be working with 800x80 internally. A single method to make a sparkline in Graph might be useful.  Just to give folks a convention. I hadn't even considered the possibility of using Scruffy for sparklines -- but that's a very interesting idea. Resizing at raster time was thrown in there because it seemed to produce slightly more readable text than directly rasterizing SVG at smaller sizes.  But something like sparklines wouldn't use text anyway, so you probably don't want resizing going on.  I'll make that an option you can specify when desired, it probably should have been optional all along. Since you haven't done the pie layer yet I have a suggestion.  Putting little pie chart slices (like sparklines) next to an index for a big pie chart is a nice alternative to a bunch of callouts or an index with simple box colors. Great idea! Some of the svg options like stroke and fill could use refactoring.  In particular, there's no way to access stroke-dasharray for the line graphs right now (that I can see anyway).  You probably were headed that way. I do want to provide a way to access those attributes easily, but honestly I haven't thought of a really great way of providing that yet.  Every graph type could have multiple SVG elements, each with their own stroke and fill styles, for example.  I just haven't come up with a good conceptual way of allowing for that yet, and in the (temporary) absence of a great solution, I haven't wanted to add a mediocre one.  As you use it, think about how you'd want to access that information during the graph-building process and let me know. I like the design.  Didn't take very long to get my head around it.  I'd even venture a guess that this could end up the de facto graphing solution. Too kind!  There are definitely some fun things I wish to do with this library in the future, especially as SVG becomes more accepted and useable over time (hopefully!).  For example, floating around the Nagilum lab is a functional prototype of a Scruffy SVG graph that can be continually updated in real-time via Juggernaut with values generated from model observers.  There are definitely some interesting possible applications for something like that. Great feedback, thanks so much!  -Brasten

_______________________________________________
PDXRuby mailing list
PDXRuby@lists.pdxruby.org
IRC: #pdx.rb on irc.freenode.net
http://lists.pdxruby.org/mailman/listinfo/pdxruby