API Docs Comments
-
-
hm...
What is the URL you use for it?
Mine just get redirected to this:http://code.google.com/intl/nb/apis/sketchup/docs/ourdoc/webdialog.html
Note the/nb/bit - I think it's some localization redirection and the comments are missing from where I get redirect - despite everything is still in English. -
-
Thanks.
I just tried in Firefox to change my preferred language from Norwegian to English - and the comments re-appeared.
I don't understand why Google pages keep messing about like this.... -
TBD said he was working on (or at least planning) a Ruby on Rails documentation app for the API. Any word on how it's going?
-
As an experiment, I used the skx project wiki to fill-in all the API classes as templates. My computer counted 1042 methods in the API that would need filled in. It's a huge amount of work even with a small army of volunteers.
But there are some definite advantages to true community documentation.
Here's the index wiki page: http://code.google.com/p/skx/wiki/ClassIndex
If anyone is interest, I can add you to the project in order to allow editing - just shoot me a PM.
-
-
Its great Jim! I've already done the entire constructionpoint class.
-
@chris fullmer said:
Its great Jim! I've already done the entire constructionpoint class.
@unknownuser said:
point1 = Geom::Point3d.new (10,0,0)Spaces between method name and parentheses yields warnings:
(eval):894: warning: don't put space before argument parentheses -
Would be nice if the classes listed what class their inherit from.
-
-
Eaxctly!
I copied that example from the API and I didn't notice the extra space there.
Chris
-
I added Parent reference.
And condensed the steps to create the sample CPoint in the example. (I don't see the need for all the small steps that the Google API has. At least not when they are just there to create sample objects to later demonstrate the method.)
Also added a comment of the return value in the example. Something I have been missing in the Google API docs.
Agree or disagree?
-
Jim, I just noticed the label system. You had labelled the classes inherited from Drawingelement. Nice system of organising.
-
@thomthom said:
im, I just noticed the label system. You had labelled the classes inherited from Drawingelement. Nice system of organising.
Yeah, it worked out nicely. I can't say I planned it that way, though!
-
I think we can do the same for Entity, Tool, and Observers. Though observers are not inherent from an Observer class, could be nice to have them labelled like that?
-
@thomthom said:
... Though observers are not inherent from an Observer class, could be nice to have them labelled like that?
One of my peeves with the SU API. There should be a Sketchup::Observer common class, which could have been a subclass of the Ruby base class Observer.
-
Is there a name for the classes that don't really exist other than to define an interface?
For example, there is no actual Tool base class in Sketchup. It's just a convention. An instance of any object can be a "Tool" if it responds_to certain instance_methods.
-
@dan rathbun said:
I called it a "protoclass" (but not sure I used the correct term.)
@unknownuser said:
(http://dictionary.reference.com/browse/proto)":2sb0s94w]proto-
a combining form meaning “first,” “foremost,” “earliest form of,” used in the formation of compound words ... -
@jim said:
For example, there is no actual Tool base class in Sketchup. It's just a convention. An instance of any object can be a "Tool" if it responds_to certain instance_methods.
Reference, a topic at GoogleGroups:
@unknownuser said:
(http://groups.google.com/group/sketchupruby/tree/browse_frm/thread/6e6ead6cade3807a/440e3c753370ab23?rnum)":c5ik998j]
@unknownuser said:(http://groups.google.com/group/sketchupruby/tree/browse_frm/thread/6e6ead6cade3807a/f1c8fdd8b6d98c72?rnum)":c5ik998j]2. I am sort of puzzed about what makes a tool. Is it the fact that it uses "Tool" methods?
Yes it is strange. There is not a Sketchup::Tool protoclass actually defined (but there could be, and might be argued, should be.)
So actually what makes a tool is that Sketchup treats an object as a tool if you call Sketchup.select_tool( object ); as up to that point Ruby and Skecthup would not know what it is supposed to be.
So then, SU assumes that it 'could' have any of the standard tool callback methods. I think .activate would be considered as a required method. While the tool is active, Sketchup sends information to the object by calling the method names defined in the API.
I called it a "protoclass" (but not sure I used the correct term.) IF there was a Sketchup::Tool class (and there really should be to be 'proper' OOP Ruby,) then it would called the superclass of the custom Tool subclass(es) that we write.
It would NOT be a baseclass, because they are defined at the toplevel, and generic to the entire Ruby world, not just Sketchup.
Advertisement