“Support” is not the correct term. The code loads all the DLLs of their “native” importers during the startup routine. However, a bug in any of these DLLs can crash SketchUp whilst it loads. (This happened one year with the FBX importer I think. We had to rename it until the next maintenance release came.)
The code does not differentiate between native and 3rd party files.
EDIT: After sleeping on it, I think that the crash occurred when “Import…” was chosen from the “File” menu. Otherwise SU started normally. (So the bad DLL caused the crash during some kind of enumeration for the dialog.)
So, it is likely not an ideal solution from the SketchUp QA team’s point of view. (Ie, dropping bad files into the binary subfolders and crash, end users call Trimble support with complaints.)
Well, one way of looking at this issue, is that the “picture” drawn by the official example I gave link to, “paints a thousand words”. That and the fact they exposed the importer interface with a Ruby wrapper.
Secondly, the community has logged many requests (some many years old) that have not yet percolated to the top of the priority list. One long time request was for a sister class of the
SketchupExtension class, for dependency libraries, that other multiple extensions could “require” and have the system download and install them from the Extension Warehouse. We are still waiting.
However, “the squeaky wheel gets the grease”, so I suggest filing an issue in the official public API tracker:
I am not against such a feature as I’ve myself logged many similar (ie, material collection installers, etc.)
I am just suggesting it may be a very long wait.
The employees are generally not allowed to disclose any future plans publicly, especially not on a mere forum.
Trimble is publicly traded stock and feature / product announcements are strictly controlled because the design software business is very competitive. Most customers will first hear of new features when they have been implemented and released. (This happens usually 2nd half of November.)
I don’t read minds. But if I had “insider information” it would be protected by a non-disclosure agreement and I would not be allowed to discuss it with anyone who was not a signatory to the same agreement.
If they have not decided to already implement such a feature, it is likely not going to happen this cycle, unless this cycle’s targeted areas of improvement include that part of the codebase for installing resources. Ie, they (as explained publicly in the past) save up and collect requests and improvement goals into groups of like kind that restrict work to the same general parts of the codebase.
So, ordinarily, I’d say you’d be a year and 8 months from any implementation if they decided to bump this to the top of v2020’s goals. But, you might get lucky, as I said they might be working this cycle on that part of the codebase.
The only two things to do is, … file a feature request and wait, …
or go the extension route with the DLL / Dylib files loaded from the importer extension’s