What does SketchUp 2013 do for developers?

Chiefwoodworker

What concretely is it that you were expecting of this release?

What concretely do you think Ruby 2.x is going to give SketchUp?

I don't believe I ever said the 2013 release ought to have been Ruby 2.0. If I did I stand corrected. What I believe I said was that there should have been some movement in the right direction.

I'll answer you question specifically in a moment. But here is an indisputable fact: SketchUp without a Ruby API is a toy and has no significant commercial value. The developers showed genius in three areas. They kept SketchUp strategically simple so that it was easy to learn and use. They provided a Ruby API to allow users to plug holes in any particular are of use. And they set a price point (and later a free point) that made it easy to adopt. I suspect they knew what they were doing when they made the Ruby API the jewel of SketchUp.

Fast forward and we see two major releases of SketchUp that doesn't address the jewel in any way; nor does it address the ease of developing plugins for SketchUp and neither does it improve functionality, performance or bug fixes that the user can see (they may be there but they don't seem to be visible yet). This seems like a cardinal sin to me.

I have wanted some help for developers in debugging and testing code. Quite some time ago I and others suggested integrating Test Unit into SketchUp. When I saw the beta Developers Tool (which I now make extensive use of)I was so happy I could wet my pants. Then 2013 came out and not even a hint of test and debug help.

The Ruby Console is next to useless. There have been several plugins to work around it that have been helpful. You can't clear the Console, enter multiple lines of code or reload a script. Again, Developer tool hinted of going in that direction, but alas no help.

Why, after the last two major releases of SketchUp, are the Mac and Windows versions of Ruby interpreter still different? Is it because the SketchUp team likes to see the third party developers fix their code when they get different results on different platforms?

There are numerous API method bugs that have been outstanding for some time (e.g. observers onSelectionBulkChange and onSelectionCleared). I haven't checked yet to see which are solved and which are not, but it is a sign of the problem that Trimble has not published what problems have been resolved in this release. It's up to the users to test for fixes.

Because the Ruby API is the crown jewel of SketchUp it would be nice if there were a long range road map for it. And even nicer to see an incremental step on that road map. Wouldn't it be nice if we woke up to a major release in the future where Rails was also integrated into SketchUp and the WebDialog would be history. And we might have database support. Further, wouldn't it be nice if some IDE like RubyMine understood, or was at least aware of, SketchUp Ruby class and method extensions? You can't get there if you don't take a step in that direction.

What I read into this release is that Trimble has a plan for SketchUp, but long term I doubt the large majority of plugin developers is going to like it. The Ruby API may be dead in favor of the C++ API. The free version of SketchUp may be completely decoupled from SketchUp and may itself be eliminated. I hope I am wrong, but that is the flavor of this release.

I am done on this subject. I have gotten this off my chest and I am going to do useful work.

Aerilius

I don't see a favor of the C++ API. In fact it was almost dead under Google, and is now only near equally alive as the Ruby API.

Chiefwoodworker

@adamb said:

@chiefwoodworker said:

I am done on this subject. I have gotten this off my chest and I am going to do useful work.

Probably for the best as you haven't actually articulated anything but a few grumbles. You do know, nobody actually develops using the Ruby console.. We use an IDE like Visual Studio or Xcode or Eclipse.

"Integrated with Rails." Are you insane? Why would you inflict a molasses-slow, bloated 'experiment' on a CAD package? Why? Just bonkers!

"The Ruby API may be dead in favor of the C++ API. ... I hope I am wrong, but that is the flavor of this release." Nobody has said that, you're just hearing what you wish to hear.

Can I just say "Bonkers" again. Ah, thats off my chest.

Gee, isn't that sophisticated. Visual Studio, Xcode, Eclipse. Well I use RubyMine IDE. Sorry if my choice of IDE doesn't live up to yours. And have you ever heard of Unit Test and Developer Console, a console that might have replaced Console if not pushed aside by EW? You might ask thomthom about it.

Do you know what Rails is? Are you aware that it would have nothing to do with rendering performance any more than WebDialog does, and it would certainly be more stable and useful than WebDialog. Bloated? Experiment? You might want to explain that.

Of course no one at Trimble has said the Ruby API is dead. That would be suicide. But if you read between the lines with the last two major releases you have seen no improvement in it, and if you look at the business Trimble is in you might conclude there is no need for it either.

You can say "Bonker" all you want. You live in a free society.

Trogluddite

@adamb said:

What concretely do you think Ruby 2.x is going to give SketchUp?

I'd happily settle even for 1.9.x - just for pure speed, if nothing else.
Might also stop me from writing so many syntax errors while I'm trying to get my head around the SU API!

AdamB

@chiefwoodworker said:

I am done on this subject. I have gotten this off my chest and I am going to do useful work.

Probably for the best as you haven't actually articulated anything but a few grumbles. You do know, nobody actually develops using the Ruby console.. We use an IDE like Visual Studio or Xcode or Eclipse.

"Integrated with Rails." that's insane! Why would you inflict a molasses-slow, bloated 'experiment' on a CAD package? Why? Just bonkers!

"The Ruby API may be dead in favor of the C++ API. ... I hope I am wrong, but that is the flavor of this release." Nobody has said that, you're just hearing what you wish to hear.

Can I just say "Bonkers" again. Ah, thats off my chest.

thomthom

@chiefwoodworker said:

And have you ever heard of Unit Test and Developer Console, a console that might have replaced Console if not pushed aside by EW? You might ask thomthom about it.

I'm not following you on this one... The project has seen activity since it was released at Basecamp... https://github.com/SketchUp/sketchup-developer-tools/network
It's all there for anyone to join in on.

@chiefwoodworker said:

Do you know what Rails is? Are you aware that it would have nothing to do with rendering performance any more than WebDialog does, and it would certainly be more stable and useful than WebDialog. Bloated? Experiment? You might want to explain that.

Not following you on this one either. It's a web-framework. How much would that benefit SketchUp programming?

@chiefwoodworker said:

Of course no one at Trimble has said the Ruby API is dead. That would be suicide. But if you read between the lines with the last two major releases you have seen no improvement in it, and if you look at the business Trimble is in you might conclude there is no need for it either.

We're not reading along the same lines. Why would SketchUp develop a repository for Ruby API extensions if it where not to invest further in it? And this the the very first major Trimble release - after only a year since they changed owners. You're extrapolating data-points from different data-sets.

danielbowring

@thomthom said:

Not following you on this one either. It's [ruby on rails] a web-framework. How much would that benefit SketchUp programming?

Ah, but if we dropped[sup:224df3da]†[/sup:224df3da] window.load for javascript<->ruby communication and used xhrs instead, having a web framework could be really useful! That said, rails (and most frameworks) for that matter might be a bit bloated - given the situation many features would likely never be used. What would likely be better would be to implement something like wsgi or rack and then allow developers to deal with requests appropriately (and hopefully a dominant method/framework will arise, which can then hopefully be made available on the extension warehouse as a requirement/dependency library)

[sup:224df3da]†[/sup:224df3da] I don't mean remove it; just make it a secondary, legacy option.

Sidenote: I'd still love to see a newer ruby version (1.9.x, 2.x), a complete ruby install dedicated to SketchUp (no external installation required, full library available), and rubygems support (Possiblities: Add a custom named executable to the PATH skpgem install ... or give us a method to get the path of the executable #{Sketchup.GEM_PATH} install ...`` or give us a wrapper Sketchup::Gem.install(...) unless Sketchup::Gem.installed?(...)). Also, a single WebDialog implementation. Use something like WebKit or Gecko so we get the same behavior on both OSX and Windows, as well as some cool new toys (developer kit, HTML5 and CSS3 features, ...)

AdamB

@unknownuser said:

Sidenote: I'd still love to see a newer ruby version (1.9.x, 2.x), a complete ruby install dedicated to SketchUp (no external installation required, full library available), and rubygems support (Possiblities: Add a custom named executable to the PATH skpgem install ... or give us a method to get the path of the executable #{Sketchup.GEM_PATH} install ...`` or give us a wrapper Sketchup::Gem.install(...) unless Sketchup::Gem.installed?(...)). Also, a single WebDialog implementation. Use something like WebKit or Gecko so we get the same behavior on both OSX and Windows, as well as some cool new toys (developer kit, HTML5 and CSS3 features, ...)

Yes, moving to 1.9 sound like a good idea. No idea how much internal SU work that would require in that clearly there is a lot of code inside the Ruby part which is handling the bridge to internal SU structures. I did a quick sniff test on 1.9 just now and it didn't leap out at me that it would break existing C++ Extensions.

But again if I were in their shoes, you'd have to ask the question as to what engineering gives greatest bang-for-the-buck. Is Ruby 1.8.6 actually blocking adoption of SU? Probably not, but as you say, it perhaps limits some new uses.

A fundamental problem Team SU need to figure is how you offer flexibility/extensibility while discouraging devs bolting on stuff that compromises performance. Perhaps some Extension Warehouse QA should have some "Performance Gates" that are required to go through?

The other thing I would say, having dealt with thousands of SU users, is that while models are getting much larger, it astonishing the number of users who still hang on to a 6-7 year old laptop with a very low power graphics card. Just investing in a modern computer - and certainly a modern graphics card will have huge effect on SketchUp performance.

FWIW I point my users at this website to compare their card and see how very slow they are compared to even a modestly priced modern card: http://www.videocardbenchmark.net/gpu_list.php

Adam

thomthom

@unknownuser said:

no external installation required, full library available

You mean full library as in the Ruby Standard Library?

danielbowring

@thomthom said:

You mean full library as in the Ruby Standard Library?

Yes.

thomthom

@adamb said:

A fundamental problem Team SU need to figure is how you offer flexibility/extensibility while discouraging devs bolting on stuff that compromises performance. Perhaps some Extension Warehouse QA should have some "Performance Gates" that are required to go through?

I hope the QA checks observer events, context menu handlers and validation procs.

AdamB

@unknownuser said:

@thomthom said:

Not following you on this one either. It's [ruby on rails] a web-framework. How much would that benefit SketchUp programming?

Ah, but if we dropped[sup:33hprjh2]†[/sup:33hprjh2] window.load for javascript<->ruby communication and used xhrs instead, having a web framework could be really useful! That said, rails (and most frameworks) for that matter might be a bit bloated - given the situation many features would likely never be used. What would likely be better would be to implement something like wsgi or rack and then allow developers to deal with requests appropriately (and hopefully a dominant method/framework will arise, which can then hopefully be made available on the extension warehouse as a requirement/dependency library)

I build a nano-webserver (1k code) into my tech both for debugging (point a browser at it to query stuff) and to better support integrated solutions. You can see an example by running LightUp Player and pointing your browser at http://localhost;8080

It would be straight forward to build a well-known socket into SU for WebKit comms.

Or would it better to finish off their original (not unreasonable) approach of having a skp:// scheme handler?

Adam

danielbowring

@adamb said:

It would be straight forward to build a well-known socket into SU for WebKit comms.

Or would it better to finish off their original (not unreasonable) approach of having a skp:// scheme handler?

Adam

http would probably be better because it would "just work" on things like jQuery.ajax. Just bind listen on a particular port (if already taken, just keep trying the next one). Them it's just of matter of the client getting the information - for pages served by it it is as simple as document.location,, and for remote stuff maybe include it in the user-agent or some other standard header (like X-SketchUp-Server: localhost:8042). Then you're communication channel is good to go!

Edit: Idea: let plugin developers define subdomains (implemented by local DNS rules). That way we can separate out authors content over a fake domain. (eg, author.sketchup-dialog.com, then just use the header to tell the port it is listening on.

AdamB

Nice.

And I guess it would be trivial to map skp:// requests into this automagically.

tomot

NOTHING! Zero! Nada!

One of the main problems I have, is verifying that the script runs in SketchUp.

1. Doing a load "Ruby.rb" in the Ruby Console does NOT always clear out the previous values. Hence I don't even bother to use it anymore. Its sheer insanity to constantly reload SU, then the script to see if the script runs. After 8 hours of programming a Ruby script, I spend more time doing 1. then actual programming.

If anyone here has ever written code in GDL for ArchiCad, you will discover that all the GLD code runs within the Code ArchiCad window, while the results of the code run within a 3D ArchiCad Window. Any changes in the code are immediately translated to the 3d window, while all code errors are immediately flagged in the Code window. You never have to quit ArchiCad while your writing code in GDL. ArchiCad also provides a standard user interface under which all user code is displayed and runs.

Now that's what I call an API!

dacastror

In my opinion there are several things that are doing well in Trimble
But I see a couple of errors:

when opening sketchup 8 will not get a notice to upgrade to 2013 version (because of this, they will lose millions of users)
in "Sketchup 2013 free" entities transformations performed more slowly than "Sketchup 2013 pro" and "Sketchup 8". These things are really serious errors

(google translator)

Rich O Brien

You were always told to update regardless of the version for the last few releases.

And there's no performance difference between Make and Pro from what I can tell.

thomthom

@dacastror said:

when opening sketchup 8 will not get a notice to upgrade to 2013 version (because of this, they will lose millions of users)

It does update. Unless you have a firewall that blocks access.

@dacastror said:

in "Sketchup 2013 free" entities transformations performed more slowly than "Sketchup 2013 pro" and "Sketchup 8". These things are really serious errors

Got a reproducible sample case for this?