SketchUp Ruby API Extension Library

[Jim]

I have started a code repository to organize all of the code and snippets around the forums, and on my hard disk.

My hope is that it can be organized and packaged into a versioned library - making it easy to install and upgrade; not to mention creating a well-documented 'standard' library of extension methods for SketchUp developers.

My other hope is that the many folks in this community will want to "share the blame." Seriously, a library which provides some basic (and not so basic) methods could go a long way in advancing SketchUp even further.

So to facilitate these goals, I have created a mercurial repository on Google Code:

skx - A Community-Maintained Ruby Language Extension Library for Google SketchUp

If you have an interest in being a project member, please reply or shoot me a message.

[Chris Fullmer]

Hi Jim, I'm very interested in this project. Of course you do realize that now this means I a going to have to re-configure my /plugins/ Hg repo too accomodate multiple projects Oh well, I'm sure I'll get over it.

I think this kind of project sounds great, and I've got a few snippets of code that I'd like to contribute to it. I am finally done with school as of about 3 hours ago, so I'll see if I can get some of my code together and cleaned up and ready to post.

Thanks for organizing it.

Chris

[Chris Fullmer]

Jim, I was wondering if it is possible to have a library like this check the internet to see if an update is available everytime it turns on (if there's an internet connection). Just to keep it updated. Maybe even the server can push the new version onto the user's machine.

Chris

[chrisglasier]

This is something different from the plugins business, right?

Chris

[Jim]

Hi Jim, I'm very interested in this project. Of course you do realize that now this means I a going to have to re-configure my /plugins/ Hg repo too accomodate multiple projects Oh well, I'm sure I'll get over it.

Excellent, thanks Chris!

Now I an going to explain how to set it up so you do not have to re-configure (much.)

Create (if there is not already) a file named .hgignore in your Plugins repository. In it, add the following simple lines:

Code: Select all

syntax: glob
skx/*


hg will now ignore everything in the skx directory as long as you don't tell hg to add it.

Since skx is designed to be in Plugins/skx, you can clone it into the Plugins folder. So you have a repository in your repository, but so what. Just don't add skx to citygen.

[Jim]

This is something different from the plugins business, right?

Chris

Chris,

I'm not sure what you mean by the plugins business, but I think you mean CityGen because we talk more about the source code management software and where to locate its repository than we talk about CityGen.

This project is the start of a general-purpose library of Ruby methods for extending SketchUp's Ruby API. I'd like to have you on-board, if possible. Specifically, I'd like to see some WebDialog/Ruby/Javascript interface libraries so the average person can create decent dialogs without needing memorize 4 or 5 O'Reilly books.

[chrisglasier]

I'm not sure what you mean by the plugins business ...

I was thinking of the SCF extensions index really.

but I think you mean CityGen because we talk more about the source code management software and where to locate its repository than we talk about CityGen.

Not really, but later, namesets might become useful not only for linking and crosslinking the code but also the models (both are object-oriented).

This project is the start of a general-purpose library of Ruby methods for extending SketchUp's Ruby API. I'd like to have you on-board, if possible. Specifically, I'd like to see some WebDialog/Ruby/Javascript interface libraries so the average person can create decent dialogs without needing memorize 4 or 5 O'Reilly books.

Yes I would be happy to help where I can, but I get a bit lost with the codespeak - I am sure you remember I'm only an old builder. Tip me the wink if something specific comes up though.

Chris

[Jim]

Yes I would be happy to help where I can, but I get a bit lost with the codespeak - I am sure you remember I'm only an old builder. Tip me the wink if something specific comes up though.

Ok, great! I've added you to the project page.

Jim, I was wondering if it is possible to have a library like this check the internet to see if an update is available everytime it turns on (if there's an internet connection). Just to keep it updated. Maybe even the server can push the new version onto the user's machine.

I think so. I don't know about push, but a "check for updates" is an option. The built-in socket calls are very limited in Sketchup, so I am not sure if it is the best to use. But I also don't know if anyone has written networking code that could go fetch the files and that works in Sketchup.

I added you to the project also.

[thomthom]

I think so. I don't know about push, but a "check for updates" is an option. The built-in socket calls are very limited in Sketchup, so I am not sure if it is the best to use. But I also don't know if anyone has written networking code that could go fetch the files and that works in Sketchup.

This is possible if we use a webdialog to fetch the updates with an AJAX call.
There could be an XML file with plugin name, info, date time, and download location (etc etc). The Javascript would then make an HTTP request for that XML file check it with the local installation. If there's an update it request the updates. (Not sure if you can svae files to disk via JS - but maybe it can forward the file content to the ruby end and have ruby store it. ..hmm... just came to think of something - I think webdialogs transfer data via the webdialog's url... that might cause problems with transferring files. might have to make ruby download the files after all.
This is something I'd been hoping to look into - as I'd love to have a plugin updater.

[thomthom]

Hi Jim, I'm very interested in this project. Of course you do realize that now this means I a going to have to re-configure my /plugins/ Hg repo too accomodate multiple projects Oh well, I'm sure I'll get over it.

Excellent, thanks Chris!

Now I an going to explain how to set it up so you do not have to re-configure (much.)

Create (if there is not already) a file named .hgignore in your Plugins repository. In it, add the following simple lines:

Code: Select all

syntax: glob
skx/*


hg will now ignore everything in the skx directory as long as you don't tell hg to add it.

Since skx is designed to be in Plugins/skx, you can clone it into the Plugins folder. So you have a repository in your repository, but so what. Just don't add skx to citygen.

This is something I have to do as well.
what I'm curious about is: "hg" is a name Chris made for the CG repository? (I thought it was come odd naming convention by the repository software.)

[remus]

I think hg is used for all mercurial folders (trivia: hg is the atomic symbol for mercury, thus mercurial.)

[Jim]

hg is the mercurial command-line executable - I tried TurtleHG, but found it slow so I installed the command-line version.

Also, this .hgignore file will tell hg to ignore everything by default unless explicitly added.

Code: Select all

syntax: glob
*


[thomthom]

Since skx is designed to be in Plugins/skx, you can clone it into the Plugins folder. So you have a repository in your repository, but so what. Just don't add skx to citygen.

How would I clone the skx repository?

hg will now ignore everything in the skx directory as long as you don't tell hg to add it.

I'm confused by this. Doesn't skx use hg?

[Jim]

I'm confused by this. Doesn't skx use hg?

ignoring files by pattern does not mean you can not still add individual files to the repository. It only means they will not be acted on by default. So I can have 1,000 files in the working directory, but unless I explicitly add them to the repository (hg add filename), they are ignored by hg.

This is good because if I type 'hg add' with no filenames, EVEYTHING in my Plugins folder would get added to the repo on next commit. I can of course revert that before pushing, but why worry about it when I can ignore them?

So yes, skx does use hg. It is a hg repository. It is located in my Plugins folder, which happens to also be a hg repository. But Plugins is set to ignore (not act on) everything unless explicitly added. So unless I accidentally type 'hg add skx' while working in Plugins, I don't need to worry about adding anything unwanted to the Plugins repo.

My Plugins repository is not a clone of citygen, by the way.

[thomthom]

Earlier today I saw lots of files when I used the Coogle Code browser of the repository. From the Updates page I only see a readme file being added since then, but I can now only see the readme file. All other files are gone. What happened? Did you remove the files?

[Chris Fullmer]

Its possible to reset a repository on googlecode so it removes all files and repo history. But you can still the big history here:

http://code.google.com/p/skx/updates/list

[Jim]

Its possible to reset a repository on googlecode so it removes all files and repo history. But you can still the big history here:

http://code.google.com/p/skx/updates/list

Yeah, I reset it. Sorry.

[thomthom]

Ok.
Are you interested in having some code snippets uploaded? Or should we wait? What would the procedure be?

[Jim]

Fire away!

I have 2 organization schemes in mind, but it's hard to tell which way to go without seeing what is available.

First would be a file-based organization where loosely related methods are stored in a single file.

Code: Select all

Plugins/
  skx/
   selections.rb <-- methods relating to the Selection object
   groups.rb <-- methods relating to Groups


The other is a folder-based:

Code: Select all

Plugins/
  skx/
    selection/
      selection_method_a.rb
      selection_method_b.rb
    group/
      group_method_a.rb
...


The file-based solution has fewer overall files. The folder solution has the advantage of users being able to require exactly the methods they want, and none they don't.

As for the scripts, the file-based scheme would look like:

Code: Select all

# my plugin
require 'skx/selection.rb'


Where the folder-scheme would be slightly more typing to get what you want..

Code: Select all

# my plugin
require 'skx/selection/selection_method_a.rb'


If I need to decide today, I would go with folders. Each method (or very closely related methods) go in a small file in a folder. Then, you can still create a file that can require the entire folder if you so desire.

I just pushed up a small file with 4 basic Sketchup::Selection methods.

[Jim]

I reset the repo because I wanted to make a good-faith attempt at getting permission before adding other peoples work to the code base.

[thomthom]

I added a couple of snippets that was ready to upload. I'll upload more once I dig through my random collection.

[Chris Fullmer]

Jim I was wondering how broad in scope is this library supposed to be? I have a method for creating bezier splines. It either actually draws it or just returns an array of its points.

So is that something worth putting into this library? And if so, does it need its own new folder/file?

Chris

[Jim]

I could have sworn I replied to this already...

I think a broad scope is fine as long as things are documented well. Documentation si going to be a big job.

As more methods get added, relationships and patterns will emerge that will lead to an organization scheme. For now, I am fine with a catch-all 'misc' folder for files that don't have an obvious place.

have a method for creating bezier splines. It either actually draws it or just returns an array of its points.

This sounds like it should be split into a backend bezier math library, and a separate drawing method. Each sound useful on their own, so maybe they could each be made into something more general.

[thomthom]

creating a well-documented 'standard' library of extension methods for SketchUp developers.

Is the intention to extend existing Sketchup classes with methods?
Or add other classes/modules?

I've never really extended the SU classes as I've never been sure if they'd interfere with other. Instead I made separate modules - even though it'd be more convenient to extend existing.

[thomthom]

I'm wondering if maybe some methods that simplifies common Transformation actions would be useful?

Personally Transformations is something that I've had to twist my head a bit to understand. Some helper methods might make it easier for people new to this. As well as working as examples of how they work - provided they are nicely commented.

[Jim]

I'm wondering if maybe some methods that simplifies common Transformation actions would be useful?

I actually added a Group.moveto(Point3d) method this morning. It's a common thing to want to do with a Group. But does it work with other transformations? I'm not sure.

Group.rotate(angle, X_AXIS) - not bad, but if you want to use the Group's axes, then you still need to write
Group.rotate(angle, Group.transformation.xaxis) which I guess is a little better than

tr = group.transformation
Group.transform!(Geom::Transformation.rotation(tr.origin, tr.xaxis, angle)

But is the first examples so much better that is needs to extend the Group class. I'm not so sure.

Is the intention to extend existing Sketchup classes with methods?

Yes it is. For the most part, people have (rightly) avoided extending SketchUp's classes. But this library is the right place to do it.

[thomthom]

Yes it is. For the most part, people have (rightly) avoided extending SketchUp's classes. But this library is the right place to do it.

Ok. I suppose that the methods are reviewed for potential conflicts?


I added a Group.real_parent that work around an SU bug where Group.entities.parent doesn't return the definition. I didn't name it .definition as I've seen some code out there that works with SU4+. Maybe my method should be merged with that method?

[thomthom]

Anyone talked to any SU devs about this?
Maybe they have a reserved list of methods.

[Jim]

Anyone talked to any SU devs about this?
Maybe they have a reserved list of methods.

I sent a message to Scott asking him to review and comment, if possible.

[Jim]

Do I understand correctly that Model.start_operation calls can not be nested? If calls do become nested, is there a performance penalty, or stability issues?

I'm am thinking about adding in some protection to start_operation to prevent nesting - raise an exception or something. What do you think?