How to Use Graphing Gem in SketchUp Plugin
-
Hello,
I am on a team that is developing a plugin for SketchUp, and now we would like to add in a tool that can display some of our information as easy-to-read graphs. We have found a couple ruby gems that fit our needs perfectly: googlecharts and gruff (either one would work). It is important that our plugin can run even on machines that do not have ruby installed, and we are not entirely sure how to use ruby gems with the ruby interpreter that is built in to SketchUp. We have tried including the files for the ruby gem with our code, but it seems that we keep running into more files needing to be required, i.e. googlecharts required yaml which required something else...
Does anyone have experience with this sort of thing? It is foreign ground for us, and we are not finding a lot of information on it from the searching we have done.
Thanks,
Ryan -
The requirement to run on a machine without a local installation of Ruby complicates the situation. Rubies generally assume that they are running on a standard installation. This means they expect all the standard distribution libraries, as well as their own suite, to be available where Ruby can find them. But SU ships with a bare-bones interpreter without any libraries. So, there is no way to avoid the fact that you will need to provide every file required (recursively) by anything you want to use. It might actually be easier to include a ruby distribution with your application, though that certainly does make a heavyweight plugin! You can manipulate $LOAD_PATH to cause SU's Ruby to find required files in non-default places.
-
But, what if another plugin does the same thing?
-
@slbaumgartner said:
The requirement to run on a machine without a local installation of Ruby complicates the situation. Rubies generally assume that they are running on a standard installation. This means they expect all the standard distribution libraries, as well as their own suite, to be available where Ruby can find them. But SU ships with a bare-bones interpreter without any libraries. So, there is no way to avoid the fact that you will need to provide every file required (recursively) by anything you want to use. It might actually be easier to include a ruby distribution with your application, though that certainly does make a heavyweight plugin! You can manipulate $LOAD_PATH to cause SU's Ruby to find required files in non-default places.
This is actually the path that ended up working for use, we simply included the Ruby 1.8.6 distribution in the plugin. Not ideal, but the size wasn't too bad for our needs. We have since been able to get googlecharts working, although it would be nice to have a standalone solution that didn't require an internet connection to use. Gruff relies on ImageMagick, and we don't want to rely on users downloading another program, nor do we want to try and package that whole application with the plugin. Still exploring some different options...
For the sake of context, our plugin makes use of .epw files that contain weather data for a particular location over a typical year. We are planning on adding a tool that allows the users to view these files graphically so they can better understand how the various parameters change over the given year, and find portions of the year that may be of interest to them. Our ideal situation would be to have graphing capability without any dependency on web connectivity, but it is looking a little more difficult that I would have thought. Most information online is geared towards Ruby on Rails which makes it challenging to sift through and find options that could actually work.
Thanks for the reply though, it definitely matches up with what we thought was going on!
-
One problem is that the Set class of the Standard Library conflicts with the Set class that ships with SketchUp and will break plugins that tries to use the SketchUp Set class - such as Sandbox Tools.
-
If you're feeling especially adventurous, you could try using a
canvastag within a web dialog (explorercanvas is your friend) and then useWebDialog#write_image.Edit: Wow, I actually just had a play with that and the image quality is horrible. Is that just how it is?
Edit2: Not passing any arguments other than file location fixes the quality, but means you have to capture the full client area (including scrollbars, if they are present) -
There is no quality or compression argument (?). Or did someone try
:compressionfrom view.write_image, maybe it's undocumented? -
@aerilius said:
There is no quality or compression argument (?). Or did someone try
:compressionfrom view.write_image, maybe it's undocumented?Wrong
write_image- I'm talking aboutdialog.write_image
Edit: Wait, I'm the one misunderstanding!
Yea, as far as I know there is no compression argument for it.Edit2: It doesn't appear to take a hash-options.
However, the poorer quality only seems to happen for JPEGs. Saving it as a PNG maintains the quality but completely ignores the size arguments. -
@unknownuser said:
Edit2: It doesn't appear to take a hash-options.
However, the poorer quality only seems to happen for JPEGs. Saving it as a PNG maintains the quality but completely ignores the size arguments.whut whut?? A bug you say?
-
@tt_su said:
whut whut?? A bug you say?
Ah! Looks like it is a bug, but only in the documentation. The actual argument order is:
- filepath
- quality (0-100, 100 being best quality)
- top_left_x
- top_left_y
- bottom_right_x
- bottom_right_y
It previously appeared to be poor quality because I was using the origin (0,0) which gave the worst quality, and it gave the wrong size because when the size is invalid (or missing) it just gives the full client area.
PNG's always came out great because they are a lossless format.Props to Aerilius for guessing right
-
Ah, the docs are wrong. Why am I not surprised...
Advertisement