Twelve seconds? Wow. It takes like 3 minutes to load for me and we have broadband cable internet.
How long to load if you empty the browser’s cache?
I will check tomorrow (not at my computer any more today)
It actually loads quicker then the desktop version (with extensions)
15 seconds on a computer that never ran SketchUp Free before. That includes about a second for the initial sign in.
Since this is getting off topic I started a new topic.
2 Likes
That is a very good question. It’s one of the reasons that prevent a 1:1 match with the Desktop API. I don’t think there is any way for a browser app to access local files due to security restrictions. More likely access to files would have to be via web storage.
1 Like
I don’t think this is an unsolvable problem, as long as we can think outside the box. There exist already a lot of apps that run under confinement/sandboxing, and they only have access to their own (confined) temp folder, their own user data folder and to files that the user adds through a file selection dialog. This can be mapped to web storage. Basic extensions do not need other files than their own or those provided by API methods or through a file selection dialog.
Only some existing extensions that integrate with other installed software on the client file system (render engines, drivers, AR/VR viewers) already now take a lot of assumptions about the underlying system that are not covered by the Ruby API specification, so that need for redevelopment is to be expected.
The interesting questions are, I think:
-
How much would an extension API for Web resemble the existing desktop API?
Is the goal just to develop entirely new extensions, or create exact matches of existing extensions (ports, or even run unchanged Ruby Code)? -
Would extensions be deployed on the server part or locally in web storage?
If a brand new API is developed I hope it at least matches the ruby API well on a conceptual level. I still haven’t gotten into the C API much but think I spotted some functions that take a componentinstance as argument, even though they better represented a behavior of the definition.
My latest extension (Medeek Wall) now has the ability to import SKM files, however that requires that I manipulate these files and their textures (images) on the users local machine and then write the data to a config file that the plugin uses to store its material library (database). How would something like this work with a web based extension?
Would I have to move everything server side?
I think the best solution for such use case is to simply support SKMs directly by the API. Extracting them and manipulating images yourself shouldn’t really be needed.
1 Like
I kind of agree. I didn’t really want to go down that route but in the attempt to maintain compatibility with older versions of SU I decided not to use the SKM “as is”. Perhaps this was a fool’s errand.
But even with that aside I have other features that need to save files locally (config files). If I ever do try to port to a Web API its going to be a lot of work, I can see that already.
Everything will need to be server side, and databases (and all other data that needs to persist between sessions) will need to be stored on a webserver that the plugin talks to across the internet. I wouldn’t be able to store configs locally since you can’t be sure what computer is connecting to SU and plugin. It’s a whole different game.
Sketchup.read_default and write_default could be used for much of the config. Also methods that now save out a file or load a file could support bit stream strings as return values and parameters. I think most of the temporary files can be gotten around quite easily if just the API allows it.
Then of course we have plugins for importing and exporting, but those interact with files the user is involved with, so for that we could have a file upload form and file download capabilities.
1 Like
No… That is what APIs (“interfaces”) are for. They can abstract things away, and the implementation of SketchUp (Web) takes care of everything. Already now SketchUp for Web is loaded from the web and saves preferences and models back to the web on Trimble connect. No need to worry.
An example...
How do you save files locally? You call an API method that gives you an arbitrary string that you interprete as "file path". Then you call an API method which accepts that string with keys appended with some delimiter (file name or subdirectories) and some data. If an API behaves like that, it does not matter whether it uses a local file system or whether it is even a unit testing stub.I think it is out of scope of this discussion that we as non-SketchUp-developers or even non-technicals speculate about implementation details. The SketchUp team is genius at those things. I trust them. It will be realized differently anyways, than we speculate.
But maybe it is worth to brainstorm on a more abstract level:
- What do we imagine to create first with a first API version?
- What new ideas would a Web API allow us to realize that the desktop can’t?
- …
2 Likes
Remember this?
It looks like we have a first example in SketchUp for School : Solid Inspector
2 Likes
There was the stl export feature earlier.It use to be an extension first, now coded in the (web)core.
And solid tools as well…
1 Like
I don’t think solid tools was ever an extension, even though its toolbar is hidden by default. I can’t find it in the Extension Manager.
No, solid tools were not an extension.
Stl was refactored into a native importer/exporter because we needed it more more platforms than just the desktop.
1 Like
Interesting. So @tt_su did you manually translate your plugin into JavaScript?
1 Like
It’s not necessarily an extension anymore (see the comments above).
At minimum, the GUI and GUI bindings must be JavaScript. The analysis needs access to drawing elements in the C++ core. So if there is not already an API (to give access to drawing element methods), the analysis code could also be implemented into the C++ core directly.
1 Like