Uploading/distribution of DLL importers

Developers SketchUp SDK
1

Hi -

Sharing Ruby plugins by uploading rbz is straight-forward, I can see there is a clear process for doing that.
However, sharing importers (written as .dll) does not follow the same process - or am I misunderstanding something here?
Importers need to go into the Sketchup xxxx/Importers directory to work. So how to “distribute” Sketchup importer dlls to the community??

Thanks
JoNoS

2

There has never been a public automated mechanism for this.

  1. You could write a Ruby extension that upon startup, checks the "Importers" directory, and if the DLL is not there copies it to that folder from the extension’s distribution folder. (SketchUp itself does a similar thing for it’s set of OEM extensions.)

  2. Just post it inside a zip archive along with instructions.

  3. You could use a freeware utility that produces a standalone installer.

In any case, SketchUp needs to be started after the DLL is copied into the "Importers" directory or it will not be available to the end user.

3

Hi –

Thanks for the reply.
I feel it is kind of wasted effort if “dll distribution” is left to manage for each individual
developer… In my view this should be a “common procedure” for all developers to follow.
Anyway, assuming your suggestion 2, what is the appropriate place (or topic) in the forum to put such kind of post(s)?

Thanks,
JoNoS

4

Except that most developers are coding Ruby extensions.

Importer and exporter library development is relatively rare.
From memory, I think most of these in the past have gone the standalone installer route because it requires administrative permissions to copy files into the %ProgramFiles% path hierarchy of folders.

Likely the Extensions category. Be sure you make it clear it’s Windows only.
(The Mac editions would use a dylib I believe, and have a massively different folder structure from the Windows editions.)

5

Again, thanks for your answer.

image

As there are (at least) two paths for contributing extensions - ruby and dll - in my opinion there should be a streamlined contribution mechanism also for the dll path, that is, if Trimble wants to actively encourage dll contributions, of course.

That the installation of dlls require administrative permissions, is really another factor to encourage a Sketchup common procedure for dll installation, in my opinion.

Before I went the dll path I followed the ruby track, but this was abandoned because of poor performance. My dll importer is much, much faster than a ruby plugin!
I have observed that the author of the gITF importer claims a hundred-fold improvement factor for his importer dll vs his ruby extension. I have not really attempted to measure the exact improvement for my dll, but the improvement factor is really, really substantial. Therefore I would believe that there are cases where dll importers should be encouraged.

6

This is the “nut” of it. Are they really still encouraged ?

I think that the DLL (dropped into “Importers” folder) way is just a leftover from pre-API days.

Even for many years API extensions were also installed into into the %ProgramFiles% path. It was not until v2014 that they were finally and properly moved into the %AppData% path. (Prior to this there were all kinds of permissions issues even with Ruby plugins.)

You could use a hybrid that is distro’d as a RBZ zip archive, and has a SketchupExtension registrar Ruby script that allows it to be switched on and off.

Then a Ruby loader that implements a Sketchup::Importer which when run loads the DLL via either:

7

And again thanks for answering. I really appreciate your expertise and insight!
As per your earlier recommendation I have now dropped my dll importer stuff into the Extensions category, for anyone to use at their discretion.

I do understand that there are various ways to deal with dll installation. However, before
I throw myself into - what I consider - Trimble territory, I really would like to understand how Trimble is planning for dll handling. They have a rather new C-API, so I would expect them to have thought out a “roadmap” for such installation and usage. Do you have any insight into their visions?? Say, for the 2019 version?

I agree that the DLL dropping into the “Importers” folder is rather clumsy, however they still
support it, so what could be their plans?? Probably, you have better connections there than I have, thus my query.

8

“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 %AppData% subfolder.

9

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.