New API doc - typos and questions

thomthom

@dan rathbun said:

It would be better to have INLINE (expandable) comment block beneath each method. I know you guys can do this because you did it on the Release notes pages.

? Inline comment on the release notes?

Dan Rathbun

@thomthom said:

@dan rathbun said:

It would be better to have INLINE (expandable) comment block beneath each method. I know you guys can do this because you did it on the Release notes pages.

? Inline comment on the release notes?

Yes, instead of random (newest first,) ordered comments at the page bottom...

... a poster would click an add note button WITHIN each method section. The note would be wrapped in a collapsed DIV or SPAN that is INLINE with the method section.

At the bottom of each method would be a "plus" button that has a title "Read Notes (current_num)"

If the user wished to get more info on that SPECIFIC method, they can click the "+" button, and the collapsed DIV would expand.

The same could be true for Community Contributed Sample Code Snippets. Each method could have a collapsed "snippets" section, that works in the same manner.

For an example of what I'm talking about.. see the Sketchup Release Notes page.

thomthom

@dan rathbun said:

The same could be true for Community Contributed Sample Code Snippets. Each method could have a collapsed "snippets" section, that works in the same manner.

For an example of what I'm talking about.. see the Sketchup Release Notes page.

Oh, I thought you meant that the release notes had inline comments.

Dan Rathbun

Since we are on this subject of API page format and features....

The API is still lacking:

Fully qualified class names

The organization of the docs misleads readers in some cases. For instance they would think that the PickHelper and Menu classes (as two examples,) are within the UI namespace. But they are not. They are within the Sketchup namespace.
Another example is Vertex, the Docs mislead people into thinking it's Geom::Vertex, when it's really Sketchup::Vertex

Ancestors: The mixin modules are not displayed for each class.

It would help greatly if the output of .ancestors().reject{|a|a==self} was displayed for each class and module in the API.

# Class method
class Module
  def lineage()
    ancestors.reject{|a|a==self}
  end
  def self.lineage()
    ancestors.reject{|a|a==self}
  end
end

Constants

A constants section is needed for each class and module, to list any constants defined within that namespace.

Methods
It's not clear (for the API classes,) what are class methods, and what are instance methods. (I suppose we assume they are instance methods.)* The access is not specified. (Again we assume they are all public, I suppose.)

scottlininger

@dan rathbun said:

@unknownuser said:

@dan rathbun said:

Yea.. but the formatting sucks!

...of course if you prefer to post nicely formatted stuff to this thread, that's cool, too!

HOW! ??

I don't think it takes markup... or does it?
If so. What kind? git markup? bbCode? what?

The comments don't accept markup. I'm just saying that if you have a comment that needs code formatting or something, you can post to this Sketchucation thread.

Thanks for the extra feedback, guys. I've blocked out some time to catch up on the comments.

Cheers,

tomot

I don't think Scott really gets it!
The entire API has been written by someone that passed provisionally in middle school. Then went home and proudly displayed his/her proud parents, his/her proficiency in English.
We used to give a (PP} Provisional Pass to guest students, our government had invited at tax payers expense to receive an education in our country, before they return back to their country of origin. In some cases it was an insult to give our student a PP in line with the PP definition. We also gave most of our guest students a PP, we called it a Political Pass.

Picking at random:

Group.split

    The split method is used to compute the boolean split (map overlay) of the two groups representing manifold solid volumes (this ^ arg). If the specified objects (this and arg) do not represent manifold volumes, this method fails.

Sorry! but I don't know what this entire CODE statement means:

what is a boolean split ? (this should be underlined to a definition link)
what is a manifold solid? (this should be underlined to a definition link)
what does this mean "If the specified objects (this and arg)"
where is the (map overlay)?

Speaking of overlays: the API contains not one 3d image ................" a picture is worth a thousand words"
Many of the coded API examples, will give errors when entered into the Ruby console.
I think there is work major work still to be done!

Speaking of Work to be done:

There is handful of users at this forum that would probably love to make correction to the API.
The time it took for them to make comments could have been more productively used to corrected the API.
Why not give them access to the API server and allow them to make corrections directly?

cheers!

Dan Rathbun

@tomot said:

what does this mean "If the specified objects (this and arg)"

We've already noted that these terms are confusing. The keyword this is from Javascript, and means the receiver. (It's not a Ruby keyword. It just shows the writer had a brain-fart and his web programming mind spit out the wrong word.)

Whenever you see this in the API docs, you should replace it with the Ruby keyword self, which is the current instance object, (the object on the left of the 'dot', in this case a group object.) The argument (nicked named "arg") is also a group object.

.. so to paraphrase:

self_group.split( arg_group )

Dan Rathbun

As for the other 3D geometric terms, you'll just have to open another browser to wikipedia, and paste them in.

The API docs are a technical reference, not a tutorial. It might be nice to have definition links, but we'd rather the errors were corrected first.

I'm sure you can find a browser plugin that lets you highlight text, then right-click and have a wiki lookup link on the popup menu.

I'm using Chrome now, and when I hilight "manifold solid" in your post, and right-click, an option appears on the context menu that says: "Search Google for 'manifold solid'"
It's likely I can find a Chrome extension, that will search Wikipedia, also.

TIG

To clarify the issue on group1.split(group2) [translated a little] in the Group API notes... there are equally confusing notes for ComponentInstance instance1.split(instance2)[again translated a little]...

In fact a manifold ['solid'] group can 'split' with another manifold group OR a manifold component-instance - therefore the notes are plan wrong!
The 'argument' can be a group OR an instance.

The result is always three*** new groups - one is the intersected 'volume' and the other two are the remains of the group and the 'argument' [group or instance], the originals all deleted. The intersected volume is named 'Intersection', what's left of the group is named 'Difference1' and the group of what's left or the 'argument' is called 'Difference2'. If successful the method returns an array of these groups, the API says they are listed in that order: HOWEVER, in testing the array is in reverse order! i.e. [Difference2, Difference1, Intersection].
***Somewhat perversely if the group is wholly inside the 'argument' group/instance then the result is exactly the same two volumes you started with, but they are now recast as the new groups called 'Difference1' and 'Difference2', and although there is an 'Intersection' group made and returned in the array it contains no geometry at all [i.e. (group1.split(group2))[2].entities[0]==nil] - so it might have been better to return 'nil' instead of an array [just as it does if there's a non-manifold object passed] as there was NO real 'split' at all and the originals would then be left unchanged ? If a valid 'Instance' isn't made in code [i.e. not ...entities[0]] then you could undo the 'split' if you don't want to change the two originals - however, be aware that the undo will change the references to the originals, and these will no longer be valid, so you'll need to dig further back again to re-get the references if you want to reuse them ??
These newly made groups do reuse the two original objects material[s] and apply them logically to the 'Intersection' group as its faces' materials; however, if an original object had default materials to some faces and a material applied to the group/instance itself, then the equivalent new group [like 'Difference1'] will not replicate this; rather, the equivalent faces that had the default material will now have the group.material, the new group will have the default material, and any new 'additional' faces made during the split-operation have the default material too...
These new groups also ignore the two originals' layers, with all three new groups being always on Layer0 - so if the originals are layered and you want to keep this you'll need to get references to those before they are deleted and apply the layer to.
Attributes belonging to the originals are also not replicated in the 'Difference' groups...

In a very similar way an instance can 'split' using a group OR other instance, and it returns the equivalent three groups array etc...

Other 'boolean' operations for group/component-instance have equal poor explanations and return relatively complicated results...

tomot

@dan rathbun said:

self_group.split( arg_group )

Dan you raise an interesting issue:

A good technical doc still needs to have a highlighted or underlined link, if the common English language idiom, or word, used could be taken out of context with respect to a specific computer language interpretation. Your self_group.split( arg_group ) example should qualify for such a link.

Dan Rathbun

I don't understand... I am saying it's a typographical eror, and should NOT say "this" at all, it should say "self" instead.

Anyway.. the current API documentation system stinks, and we've complained about it for years. It seems to be a low priority for Google. (Otherwise they would have hired someone who is a API documentation guru to clean up the mess.)

IMHO it is an embarrassment for Google (as a company,) knowing the quality that they can produce for other API documentation (from other Google divisions.)

Dan Rathbun

@tomot said:

A good technical doc still needs to have a highlighted or underlined link, if the common English language idiom, or word, used could be taken out of context with respect to a specific computer language interpretation.

OK, maybe I do understand.. it's like what we do here in the forum, when we use a Ruby keyword or classname, we highlight it using the "ruby" button on the edit message toolbar. (Just like I did in the post above, when I highlighted the keyword self.

Yes I think we agree with that... keyword higlites would make the API much more understandable.

brian_concannon

Can you please send me Win32API.rb? It is difficult to find a place to download it, believe it or not...

Thanks in advance.

TIG

Brian

Please learn to use the forum's search function [top right]...
http://forums.sketchucation.com/viewtopic.php?p=380121#p380121

Dan Rathbun

Model.save_thumbnail

BUG: SU ver 7.1.6087 win32

Model.save_thumbnail (which only works for the current model,) but has a bug, in that if the model has never been saved, the method writes a blank thumbnail image to the %UserProfile% folder [actually to the current working directory,] instead of the Model folder specified in Preferences>Files>Model folderpath.

If the current model has been saved with a thumbnail, then the thumbnail image is properly saved to the Model path as set in Preferences>Files>Model.

UPDATE - the API should include aModel.refresh_thumbnailmethod, similar to (or perhaps using the same internal code as,) theComponentDefinition.refresh_thumbnailmethod.
_

rvs1977

Hi!

Under Quick References --> Method Index it will only load from "Symbol, A, B, C, D to E"... not any further.

I have the same problem in I.E. and Chrome... for more than a week now.

Dan Rathbun

All letter links (targets,) work fine for me using Chrome.

Try clearing your browser cache ??

rvs1977

Hmm... found a solution.

When I press Methods Index in the menu it opens "https://developers.google.com/sketchup/docs/methods?hl=da"

I tried to delete ?hl=da so it only said: "https://developers.google.com/sketchup/docs/methods"

Then it works.

Dan Rathbun

@rvs1977 said:

Hmm... found a solution.

I tried to delete ?hl=da so it only said: "https://developers.google.com/sketchup/docs/methods"

Then it works.

On the Google Developers site.. at the lower right, on the bottom (dark gray) toolbar, is a language change button.

Use it to switch to English ... then bookmark the page.

I also posted a API links menu that I exported out of Chrome, ...
Get it here: SUAPI_Links.zip

Dan Rathbun

"NamedOptions" OptionsProvider bugged?

I am not sure what the intended behavior of the "NamedOptions" OptionsProvider is... so...

I'll just describe the weirdness of it, that I see on the PC:

1) It is within the Model options scope, ie, accessed via: Sketchup.active_model.options["NamedOptions"]

2) It is saved with the model file.

3) But once this OptionsProvider is used within a session, all attributes remain loaded, regardless of whether the model is closed, another model opened, or just a new model opened.

An attribute of the same name, from the next file, will overwrite.
But existing attributes will remain unchanged.
If you save the second model, whether you add any attributes, or not, ALL the "NamedOptions" attributes are written into ALL subsequent model files saved during that session.

So.. if you happened to open a file, just to view it,... and it had any "NamedOptions" attributes saved,.. and then you started a new model, or re-opened another file for editing... the "NamedOptions" attributes from the "viewed" file, will propagate into your "edit" model (likely without you knowing it.)

It does not seem to be desirable behavior. I think there is a bug, in that Sketchup should clear and reset the "NamedOptions" provider when another file is loaded.

I wonder what the behavior is on the Mac when multiple files are open ??