SketchUp Ruby API Extension Library

[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?

[chrisglasier]

Can I ask if skx is intended for people like Ericschimel from this topic? If so, would sets of javascript/ruby interaction couplets be what you have in mind for the repository. I could do that over time provided I didn't have to learn too much more codelling.

The function and callback names I use with namesets are typically concatenations of device, aspect, action - e.g sceneLayersVisibility - would the repository accomodate a tree file system with subdirectories and files named as the constituent parts. I could then build a nameset (separately) to review the parts or assemble them into devices or applications. I did this before but gave it up because I was in danger of disappearing up my own ... building a nameset for the code that builds namesets.

Just let me know if I am out of order and I will shut up!

Chris

[ScottLininger]

Hey guys,

I think that this is a fantastic idea. My gut feeling is that it will take a couple of generations before reasonable design patterns emerge, however. There will need to be some sort of final arbiter of what belongs and what does not. And there need to be some rules about the kinds of things this library is meant to do.

Here's what I'd say is in scope (again, just my opinion):
1. Missing parts of the API (model.typename, etc.)
2. Bugs in the API that have simple Ruby workarounds that won't break old scripts. (can't think of an example)
3. Extensions to the API that are simple, obvious in what they do, and follow existing "standard methods" pattern. (Group.rotate! or ComponentInstance.rotx or Sketchup.is_mac?)

Here's what isn't in scope:
1. full-on scripts or Tools


The API is already extremely large, so we need to be careful to keep things as simple as possible.

I'm only one guy, but I'd vote for the file structure of one-file-per-class instead of one-directory-per-class.

I'd also vote for a simple style guide and commenting standard. RDoc is the default choice, I think.

More thoughts later on code reviews, etc...

Great idea!

-Scott

[thomthom]

How is it intended to be distributed?

As a bundle extension? Or developers adding the methods they need along with their own plugins?

I think that a bundle might be best. Otherwise we might have a version control problem. Say that one plugin comes with an older version of a module, when that's installed it might override a new one.

Fredo got his own library. That comes as a separate package. Seems to work.

[thomthom]

Ideas for methods:

• Group.definition (I saw a snipped once that was made to work with SU4+. If we had that combined with my Group.real_parent that's overcome the SU bug with mixed up Group.entities.parent references)
• Image.definition (need to iterate the definitions to find it, potentially slow on large models, but it's the only method I know of.)
• Image.entities (I found that if you get the definition of the Image you can get the entities for it, four edges and a face. Might be useful. I suggested that to ASGVis since VfSU doesn't render Images "because it doesn't have geometry")
• Sketchup.major_version
• More methods to determine the content of the selection. Useful to judge when to display your context menu.

[thomthom]

• ComponentInstance.replace
• ComponentDefinition.replace
• ComponentInstance.to_group
• ComponentDefinition.to_group

[Jim]

How is it intended to be distributed?

As a bundle extension? Or developers adding the methods they need along with their own plugins?

I think that a bundle might be best. Otherwise we might have a version control problem. Say that one plugin comes with an older version of a module, when that's installed it might override a new one.

Fredo got his own library. That comes as a separate package. Seems to work.

I agree it should be distributed as a bundle with a version. It should be made available in several common compressed formats for convenience (.zip, .rar). It is not intended to be bundled with or distributed, either fully or partially, with other plugins.

[Jim]

Scott,

Thanks for your input. I agree with most of what you wrote.

For the folder vs. file organization, I downloaded and was using the Ruby Facets library as a guide. It's worth a look if anyone is not familiar with facets.)
It is hard to make a choice this early on. The code I have is already set up in folders, but I'm not set on one way or another.

Facets also has a layered setup where it has a 'core' set of methods that are enhancements to Ruby, and a 'more' set of methods with more advanced methods built on top of the 'core' set.

Any thought about using this in skx? Our 'core' methods are enhancements to the Sketchup classes, and our 'more' library could cover practically anything else. Or is it better to completely separate them in different projects?

That is about where I want the comparison to end. I don't like how large Facets is - it seems to be full of methods written for reasons other than usefulness. For example, it defines a not_nil? method. Why?

Code: Select all

not_nil?()

The opposite of nil?.

  "hello".not_nil?     # -> true
  nil.not_nil?         # -> false


RDoc is a good choice - it can have custom output. Ideally, I was looking for RDoc to generate output in the Googe Code Wiki style so I could use the projects' wiki to host the documentation as well. But it looks like that won't be as easy as I had hoped. If it could be made to work, we could run rdoc, get the documentation as a set of wiki pages, then use the revision control software to upload the pages to the wiki.

[Chris Fullmer]

Don't forget about this thread Jim. I think Alex and you worked out a great system here for making it so ALL scripts take advantage of the new start_operation flag speed.

viewtopic.php?f=180&t=19372&start=0&st=0&sk=t&sd=a

Chris

[thomthom]

Don't forget about this thread Jim. I think Alex and you worked out a great system here for making it so ALL scripts take advantage of the new start_operation flag speed.

viewtopic.php?f=180&t=19372&start=0&st=0&sk=t&sd=a

Chris

Is it safe to force all plugins to use the Disable UI flag?

[Chris Fullmer]

Looking at it, I think my concern would only be for people who are actually using the 3rd and 4th flags. I am not familiar with 1/2 of what the code is actually doing, but this line:

def start_operation(name, flag = true, trans = false, prev = false)

Is that forcing "flag", "trans", and "prev" to be those given values? Or is it providing a default value in case the user has not given one?

Chris

[thomthom]

Yea, that's default values if user doesn't provide any. Optional arguments.

[RickW]

Jim,

Glad you're doing this. Count me in - I have a few extensions that could be of use.

[thomthom]

Here's a useful snippet I got from TIG once. Could that be added? (Ask TIG first maybe?)

Code: Select all

class Float
  def round_to(x)
    (self*10**x).round.to_f/10**x
  end
  def ceil_to(x)
    (self*10**x).ceil.to_f/10**x
  end
  def floor_to(x)
    (self*10**x).floor.to_f/10**x
  end
end


[Jim]

Jim,

Glad you're doing this. Count me in - I have a few extensions that could be of use.

Great, thank you Rick.

[Chris Fullmer]

Hi Jim, I'm getting this installed now and I want to make sure I get the path correct.

So I have Plugins\skx\{entities, face, group, image, model, etc, plus netget.rb and readme.txt}

Is that the correct path?

Then also, how does the developer initialize the library? I understand that the developer should not cut and paste from the library into their code, but rather have the users download and install the entire thing. Then does the developer "require" or "include" each file they want to use? Or is there going to be a way to make it so the entire library always loads itself and the developer just needs to call each method in the Module::method manner?

Just making sure I understand the basics before I screw up your nice library

Chris