SketchUp Ruby API Extension Library

[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

[Chris Fullmer]

OK, I found it in an earlier post that you specify that the developer would use the library with

require 'skx/entities.rb'

essentially requiring eacf file they would like to use. Would be interested in also having a loader file included so they could just require one file in the root skx folder and it auto loads all files, just in case someone regularly wants to load nearly every file? Or is that just overkill and problems waiting to happen?

Chris

[Jim]

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.
Chris

Chris,

I would like to see some cross-platform methods of passing values between javascript and ruby, so clearly would involve a ruby part and a javascript part. There seems to be a general acceptance that passing strings as JSON is the best way to go, but nothing has materialized as far as I know. Most of us are using comma or semi-colon delimited strings.

It might be cool to have a set of html widgets to use in WebDialogs if you need something basic and quick.

I would also like to provide a predictable location for installing existing javascript libraries. I know Thomthom is using jQuery in citygen, for example and I am using it on a yet unreleased plugin. Chris Phillips was also considering it for the next SketchyPhysics (but may use wxSU.)

Along the same line, there are so many useful methods (libraries) already availablein the Ruby standard library, it would be a shame to ignore - or worse repeat the effort. I was thinking we could also provide a standard location for using them. As an example, the singleton.rb file which ensures there is ever only one instance of a class - is useful for creating Observers where you really only want a single instance per model. Instead of everyone creating their own Observers, we can provide them via some kind of generator (factory?).

Observers are another entire area that could use work.

I got a little off-topic, but I hope I answered your questions.

[Jim]

OK, I found it in an earlier post that you specify that the developer would use the library with

require 'skx/entities.rb'

essentially requiring eacf file they would like to use. Would be interested in also having a loader file included so they could just require one file in the root skx folder and it auto loads all files, just in case someone regularly wants to load nearly every file? Or is that just overkill and problems waiting to happen?

Chris

I don't think it is over-kill. Each folder can have a 'loader' that requires all the files in that folder. And there can be a 'skx.rb' that loads everything, if you want.

This is one of the things that needs considered when the final layout is decided. Having lots of small files in folders gives the most flexibility (IMO). You can pick and choose single methods as needed (require 'skx/group/definition'), include all the methods in a class (require 'skx/group'), or include the while library ('require 'skx/skx'). The choice is left to the user of the library.

[Jim]

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

I haven't forgotten. I am wondering if the script-timeout I was experimenting with could be incorporated into start_operation. That way, a user would be able to set their own time-out tolerance (i.e. 10 seconds) which would then be automatically enforced by any plugin that currently uses start_operation.

[Jim]

Oh and I was thinking we could provide a mechanism to handle script configuration options - get them all in one place (or menu.) Like the /etc directory with some type of interface (if you are familiar with Unix.)

[Chris Fullmer]

I am updating the wiki right now, and finding that we need to specify the file that each method is in so that the developer can know what files to require if they want to keep it minimal.

Do you think that you will be able to get RDoc worked out to do a wiki update directly from the RDoc's? That would be very cool.

Chris

[thomthom]

I don't think it is over-kill. Each folder can have a 'loader' that requires all the files in that folder. And there can be a 'skx.rb' that loads everything, if you want.

No need for a loader for that, require_all should do the trick.


A good JSON solution would be good. I've been using a crude look-alike for one script. I was talking to one of the Google heads that was also in need of JSON. I'll see if they found a solution.

[Chris Fullmer]

No need for a loader for that, require_all should do the trick.

Ahh, good point.

Ok, Ive updated the wiki docs now for the methods I added.

Chris

[thomthom]

So are we still doing a file per method?

[ScottLininger]

So are we still doing a file per method?

I'd like to hear everyone's votes. One-file-per-method is more flexible, but it could become overwhelming with so many little files. Also, I could imagine scenarios where one extended method might need to call another, so including only a single one might not always work.

I'd argue that if you're wanting to exclude a certain part from loading, then that certain part probably doesn't belong in the project. But please don't take my opinion as law.

Thoughts?

On the WebDialog topic...

We wrote a somewhat generic bridge between JS and Ruby that we used for Dynamic Components. I learned a lot from that and would have some thoughts on how to build a new one that's truly generic and easy to use. That's almost worthy of its own big thread.

One note: I think it would be work for the JS code side of a bridge to be stored in the ruby and then dumped into the WebDialog via execute_script, so JS code side of things would call something like this:

Code: Select all

window.location.href='skp:initialize_bridge';

...and then from there would have access to whatever JS methods we implement.

[Chris Fullmer]

I think I prefer the single file approach instead of multiple files approach on this project. I am not terribly familiar with code libraries though, so this is not based on much experience.

Chris

PS I'm working on the readme.txt file. Check it out in 30 minutes or less.

[chrisglasier]

On the WebDialog topic...

We wrote a somewhat generic bridge between JS and Ruby that we used for Dynamic Components. I learned a lot from that and would have some thoughts on how to build a new one that's truly generic and easy to use.

As someone who would greatly benefit from such a resource my question is whether ease of use is Ruby/Javascript oriented or the other way round. In the case where webdialogs are used in a new form of word processing -- adding all kinds of data to models -- would an outsider (allowed?) be able to look up the JS function that imitates real world action or forced to go through the class by which Ruby implements it?

CG

[chrisglasier]

I would like to see some cross-platform methods of passing values between javascript and ruby, ....

Methods are hardly within my grasp but I am concerned and hopefully can contribute to an actionable approach to webdialogs and related resources (not just code). Please see above.

Thanks

Chris

[thomthom]

I think my vote is for one file per class/module.
I see it as either you have the skx extension - or you haven't.

[thomthom]

I'd just like to bring attention to this discussion over at the Google Code pages: http://code.google.com/p/skx/source/det ... 325827e97d