I’ve just written my first extension, but I have no idea what I should be ticking for the Windows/Mac compatibility or different versions of Sketchup? How do most developers tackle this? Run virtual machines with multiple versions of Sketchup? or assume that their extension just works on older versions unless they make use of a new API call?
Thanks
For both aspects, you can try to find people with older versions and the other platform to help you. A post on this forum or sketchUcation asking for help will usually draw at least a few offers if you extension sounds useful.
The way developers who have been at it for a while do it is to keep a collection of older versions of SU to test against (you can have multiple versions installed on the same computer at the same time without difficulties).
Regarding Windows vs Mac your choices are a) buy one of each, b) find someone who has the other and is willing to help you, c) buy a Mac and run Windows in a virtual machine (so far as I know, the opposite isn’t possible due to Apple proprietary software). Although it happens, in my experience Windows vs Mac compatibility is less of a problem than version compatibility.
Many thanks.
Am I better off listing the extension as being compatible with everything (more likely to get downloads?) and then untick the versions that I get reports of problems with? I’m just worried that starting off saying it is only known to be compatible with a single version, then most users won’t even bother trying my extension?
A couple of ideas for the Sketchup team:
As the list of Sketchup versions gets longer and longer, it seems like there should be some automated way to help speed up compatibility testing? How about a developer switch for the Sketchup Ruby library, which turns on logging of which API calls are made, and then can produce a report about which calls are being called that don’t work in which older versions of Sketchup? Would be a useful starting point for identifying problem areas to fix in an extension. And much quicker than manually going through the API docs for every call you make.
Could there be an annual report of the % usage by version of active Sketchup installs? e.g., an extension developer might not want to support a very old version if it will require a lot of extra work, and is only used by 0.2% of the active installs? Sketchup calls home each time you load it, so gathering that data should be possible?
No. This I guarantee, will give you and your plugins a bad reputation. (Making improper claims on your EW product page(s) is a good way to get banished from the EW, IMHO.)
This will not happen (by the SketchUp Extensibility Team,) because “officially” the only versions that matter, are the latest and the two previous versions. All others are unsupported and will not be getting any updates as they are considered “beyond end of life”.
Since they will not be getting updates (API or otherwise) adding a new method to the API will not help older versions anyway, as they would never get the new “report” method.
Also API changes are not the only “breaking changes”. Ruby itself has changes between 1.8.x and 2.x.x that can break plugins written for one trunk or the other.
Now, that aside, Ruby is a dynamic language that supports reflection and introspection. It is not necessary for something like this to be built into the API. Ruby already has the mechanisms to support a 3rd party report tool like this.
See: Module: Kernel (Ruby 2.0.0)
Using this will slow Ruby drastically, so only use when testing, and write the proc so it runs as fast as possible. (Ie, the example in the Ruby core doc is poor as it creates a literal format string each time the block runs. The format string should be created once with a reference outside and before the block.)
Or perhaps non-live parsing of code files. Take the YARD documentation generator for example. You could use it to parse SketchUp Ruby extensions and generate such a report. (Learning how YARD works is not easy though!)
Some current starting points:
Learn to use rescue … else … ensure clauses in your plugin methods to trap and recover from errors (and optionally write to your own logging objects.)
Try using the tools the SketchUp Team has posted for testing and debugging:
Or, use premade logging features like from the Ruby standard library:
Index of Classes & Methods in logger: Ruby Standard Library Documentation (Ruby 2.0.0)