What does SketchUp 2013 do for developers?

Chiefwoodworker

I'm pretty happy with SketchUp 2013 also. Like Thomthom, I'm not concerned that we didn't see big changes in APIs for two reasons:

Dramatic changes/additions in APIs are generally a 'Bad Thing' in realworld software engineering. What you want is incremental (ideally backwardly compatible) progression. Think of it from the POV of the developers: having a new API for the latest version fo SketchUp is all fine and dandy, but you have N thousands of people out there on SketchUp 7 and 8 using your stuff. Having to develop multiple execution paths for different versions is a PITA and adds to instability.

AdamB, the key words in your statement is incremental progression. The problem is that for the last couple of releases under Trimble we saw no progression. If that keeps up Ruby will be at version 4.0 and SketchUp 1.5 & 1.6. Then you will be discussing the need for a dramatic change in the API.

Almost all applications on the market have some kind of compatibility mode, including MS products. They may be a PITA, but software engineers get paid for the work they do and coming out with a product that is incrementally further behind each release is a death notice.

All of us (or almost all of us) who visit SketchUcation do so because we love SketchUp. We don't want to see it loose its way. If you are happy with SketchUp 2013 and not concerned about the status of the API development and bug fixes, then you are someone the development team should not be listening to, because the overwhelming feedback on this release is that it is simply underwhelming. The last release that actually added something visible to the user or developer was SketchUp 7. I for one don't like the trajectory.

AdamB

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

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

ilay7k

Tom, if you (non-officialy) work at SKu team, can you or somebody make such doc at least http://www.thirdpartyplugins.com/python_r14/modules/c4d/index.html
what's new in doc or change(see at doc with tags like "new") for watching that they really made...or seems they fools me.
They(sku) made only "Migrating a SketchUp C++ API Plugin to SketchUp 2013"-guide in docs
And i see they made unknown roadmap to 2015(after several years of silence), slapi for x64 apps?!

thomthom

@adamb said:

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

Unicode support for strings and file functions.
Being able to make use of open source frameworks etc developed for Ruby.

thomthom

@ilay7k said:

Tom, if you (non-officialy) work at SKu team, can you or somebody make such doc at least http://www.thirdpartyplugins.com/python_r14/modules/c4d/index.html
what's new in doc or change(see at doc with tags like "new") for watching that they really made...or seems they fools me.

Like this?
http://www.sketchup.com/intl/en/developer/docs/releases.php

Though there needs to be some notes for the couple of SU2013 changes. Not there yet.

And each method in the API docs has version information about when it was added.

Something like that you where looking for?

ilay7k

Thank you. Yes.
Seems v.2013 had fast public preview.
(Honestly i have not open sketchup and it's docs for long time)

Chiefwoodworker

@adamb said:

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.