Did you accidentally post in the wrong forum? There is no workbook object and no SaveAs method in SketchUp or in native Ruby...

I have a bunch of perfectly good USB 3 and Thunderbolt stuff that I want to connect without having to lug a bunch of dongles (or a multi-way mega-dongle) around. I like to pluck the card out of my camera and just shove it into a slot to transfer photos. I'd much rather have a thicker, heavier MBP with more ports and a larger battery than a fashion-conscious paper-thin wafer!

@baz said:

If I might suggest the addition of a 'kicker' at the base. (Don't know what this is called in the US. Foot room essentially). Like a normal kitchen, much more comfortable to use esp. towards the back of the planter.

Generally called a "toe kick" here.

To add to what Dave wrote, there are a lot of reasons to hang onto the previous version even after you have installed the new one and it is working. You never know what issues you might run into with the new version or how soon the authors will update your favorite extensions for compatibility. You might simply prefer the way something worked in the previous version!

A purchased single-user license never expires. I ditch the old versions only if disk space gets tight or they are hopelessly obsolete.

I'm using a mid-2012 MBP Retina. The only thing about it I would change is that I wish I had maxed out the memory when I bought it. 8GB seemed like a lot at the time, but is today sometimes marginal.

What you describe sounds like an issue that has been discussed on the general sketchup forum: Sierra added a new security "feature" to prevent a particular kind of hijack attack. See, for example, this topic:

Send to Layout not working in 2017

Had SU2013 and just upgraded to SU2017 version 17.1.173. ‘Send To Layout’ is greyed out and not functional. I haven’t changed any file names or anything. All I did was upgrade to 2017 and now it’s greyed out and not func…

SketchUp Community (forums.sketchup.com)

Unless a newly installed app is adequately signed, Sierra runs it by first copying the code into a separate random folder it creates on the disk. This prevents the hijack, but it also makes SU unable to find LayOut. The latest release of SU 2017 has been adequately signed to correct this problem, but older versions have not because Trimble no longer supports them. So, when you reinstalled SU 2015 you likely tripped this feature. In the post linked above, Barry gives one way to fix it.

Some of what you describe sounds to me like there may be subtle defects in the model itself. Vanishing is often an indicator that there are remote entities that affect zoom-extents operations. They might also affect printing, I suppose.

@pbacot said:

But hey that covers up the power port doesn't it?

There's another USB-C on the other side of the MBP. You'd have to use that for power. There is no single-purpose power port any more.

This is another reason why I think Apple went too far in their quest for paper-thinness in this latest MBP. They seem to have lost track of the things that matter to the heavy-duty Mac user vs the general public. Yeah, it's nice when a laptop is as thin and light as possible, but not when I have to sacrifice connectivity and carry around a mess of adapters!

Edit: I missed the point that you were commenting on what happens if you connect dongles to both sides.

It works fine for me too, SU 2017 on Mac. When you say "Query doesn't read out" do you mean that no popup appears at all, or that the content of the popup isn't what you expected? The utilities toolset is just Ruby, so as Dave has said, if you run it with the Ruby Console open you should see messages if there are code errors.

I sympathize!

The main problem is that the importance of tiny glitches in a model varies depending on the originating software and how the modeler wanted to use the model. The worst case is when the originator is thinking like a 2D draftsman, not a precision 3D geometry modeler. That is, if a visible or printed drawing is the desired output, you draw lines from here to there so that they look good but don't really care about minuscule glitches because they are invisible on the output. You don't care about z-axis drift because everything flattens out when printed anyway. If you are drawing outlines, not faces, who cares about invisible gaps? Even if the output is going to a CNC machine, CNC only cares about tool paths. A gap that is smaller than the cutter won't affect the machined product.

At one point I tried to create an importer for vector PDF and gave it up as hopeless. To a large degree this was because there are fundamental differences between how PDF creates a model and SketchUp's geometry database, but also it was because nearly every sample file I tested had numerous places where the thickness of PDF lines hid the fact that their endpoints did not actually coincide or that edges weren't actually collinear or parallel.

The second adapter Mike showed is to my mind just a variety of dongle. I don't like dongles because they are always at risk of getting flexed and breaking either the dongle or the port on the computer.

The photos Mike posted earlier answer one question I had about that "below decks dock", namely how does it connect. In the left image you can see a little, thin sort of flap connector going up from the dock to the USB-C port on the side of the MBP. This idea seems to me better, since battery life is one of the biggest things going to pot in Apple's relentless drive to make devices as thin as a sheet of paper. That leaves two other questions: how does it fasten to the bottom of the MBP, and how does it affect heat dissipation through the bottom (as anyone who actually uses a MBP on their lap can tell you, the bottom can get quite warm!). I guess we'll see after they are readily available on the market.

What I would really like is for Apple to "future proof" the MBP by providing some kind of system bus connector through the bottom by which users could add things such as more RAM, a different graphics adapter, bigger battery, etc. - things that are not upgradable because they are all soldered down. My cynical side says that they may avoid such a port because it would eat into their lucrative sales of new models, though those sales are sagging on their own anyway...

@jim said:

Scale the objects to some arbitrary size, and then enter the exact lengths after. You can now enter " marks without the Scale Tool switching modes.

Are you saying the Mac Scale Tool changes modes after completing the operation?

You are right. I hadn't tried that. It is inconsistent with most other tools because they don't use shift as a mode change. For example, when using the rectangle, line, move, etc. you can just do the first click, start the operation, and then type a value. You don't have to complete the mouse operation using a second click before you can press shift!

@dlp said:

I'm using decimal inches. It's the same using fractional inches. Just putting 20 in it scales 20x. If I type 20 then push the shift key to put " after it the 20 disappears and it goes back to 1.0. Seems to be a bug. I'll just start using Fredo Scale. It works.

This is a known issue on Mac because the Scale Tool uses the Shift key to change from "single-handle" to "uniform" scaling, so you can't press the shift key as necessary to type '"' for inches. The simplest workaround may be the one already shown where you draw a line at the size you want and then let the cursor snap to that. Another is to prefix the inch distance with 0' and omit the inch units entirely, e.g. 0' 6 1/2

Could you describe a use case in which this feature would be valuable? Then perhaps people can either suggest an effective way to accomplish your goal within SketchUp or get aboard to support a feature request.

@numerobis said:

@slbaumgartner said:

No 3D geometry model editing program has cracked this nut in at least two decades. There are fundamental computer science reasons why it regarded as essentially impossible. So, don't hold your breath!

I'm fully aware that it wouldn't be possible for all operations (at least at the moment) But why not use it for tasks that can be multi-threaded, like background saving or file import/export, rendering, etc.?
Examples:
Revit https://knowledge.autodesk.com/support/revit-products/troubleshooting/caas/sfdcarticles/sfdcarticles/Which-function-in-Revit-will-take-use-of-multiple-processors.html
ArchiCAD http://helpcenter.graphisoft.com/technotes/setup/software-technologies/multiprocessing-and-archicad/#Is_ArchiCAD_multi-threaded
Invertor https://knowledge.autodesk.com/support/inventor-products/troubleshooting/caas/sfdcarticles/sfdcarticles/Support-for-multi-core-processors.html
Some 3DSmax modifiers are already threaded (Bend, Skin, SkinWrap, Shell, PFlow, APEX Clothing, Delta Mush to Skin, etc.)
Not sure about Maya... i know that Maya API supports multi threading
cinema4d https://www.maxon.net/en/news/maxon-news/article/foundations-for-the-future/
Siemens NX (Parasolid) http://cadabout.ru/2016/10/28/a-few-words-about-siemens-nx-perfomance-cpu-graphic-adapter-memory-multi-core/
Grasshopper https://stevebaer.wordpress.com/2013/12/11/ghpython-node-in-code/

If there are better ways to improve the performance single threaded - no problem.

Some of the things you list can and probably are passed to separate threads, whether explicitly by SketchUp or by the operating system. For example, file writes are usually buffered by the system and actually occur after the application's request returns control. So long as the model is frozen, multiple threads could be used for rendering. But some things have to wait. For example you can't save a model while it is in the midst of being updated! And, in SketchUp's case, nobody has figured out a way to use multiple threads to capture model geometry in a database simultaneously while presenting it to the user for editing.

@unknownuser said:

@slbaumgartner said:

There is nothing the SU team can do about the basic execution speed of Ruby. They do not develop the Ruby interpreter, they just embed it within SketchUp. Ruby is not designed as or advertised as a high-performance language.

If that's really the case and they are already at the limit of what ruby is capable to deliver, then i think they should rethink their "strategy" of relying completely on ruby code for standard operations like rounding edges or processing SUbD models.

This is a misunderstanding (see also my other post). Only SketchUp extensions/plugins are written in Ruby. The core of the program is in C and/or C++. At this point in time, rounding edges and processing SubD models are not built into the core of SketchUp, they are extensions. The philosophy of SketchUp has always been to keep the core relatively simple so that the program doesn't become a bloated behemoth, and to allow specialized features to be added via extensions so that users can pick and choose which ones they really need. A friend of mine used to use the quip "I wanted a banana and they made me take a gorilla, a cage, and a zoo with it".

@unknownuser said:

(Btw. as far as i know it's also possible to multi-thread Ruby code. I don't know about the SU implementation. https://www.tutorialspoint.com/ruby/ruby_multithreading.htm)

To repeat, the SketchUp team does not develop or implement Ruby, they just embed the interpreter into SketchUp. Historically, Ruby has simulated threads rather than truly supporting them. The current versions use true operating-system threads to implement it, but layer their own scheduler atop it because too much of the standard Ruby library is itself not thread-safe. The result is that Ruby blocks the main SketchUp thread, even if the Ruby program itself is written to run in multiple threads. But even if the extension could truly run multiple threads, it would be restricted in what it could do because the core of SketchUp itself is not multi-thread for all the reasons above.

@kimi kimi said:

Slbaumgartner, I maybe have a silly question. Would SketchUp work faster if it was connected or written with some other code, not Ruby?.

The short answer is that SketchUp itself is not written in Ruby. It is written in high-performance languages called C and C++. The C or C++ code is processed in advance by a compiler program that outputs commands that directly instruct the computer's CPU. Pre-processing and talking directly to the CPU are what provide the high performance.

But SketchUp also provides an extension/plugin system by which users can add new capabilities atop the core of SketchUp. The extensions are what get written in Ruby. Ruby is a high-level scripting language. "High-level" means it provides programming features that make many complex operations easy to write, hiding all the detailed stuff needed to make them happen. "Scripting" means that the original Ruby code is read from a file and processed each time SketchUp runs; it is not preprocessed. As a result, Ruby code is in general much slower than compiled C or C++.

So, the long answer is that extensions would run faster if they could also be written in C or C++ (and some authors do write parts that way), but it is a much more technical and complicated way to go.

All are of course free and welcome to propose any features they would like. If you don't ask, you won't get! I just want to observe that some are things that have been extensively discussed before and explained why they are not feasible.

@numerobis said:

• multicore support (yes, this is the way processors evolve now - since a few years)

There have been many posts about this. No 3D geometry model editing program has cracked this nut in at least two decades. There are fundamental computer science reasons why it regarded as essentially impossible. So, don't hold your breath! In some ways this proposal is like the one a few years ago about the need for 64-bit support. They added it, and it turns out the pundits were right: the only real benefit was ability to use more memory for large models. It did not have a noticeable effect on the performance of SU.

@unknownuser said:

• faster ruby script execution! (it's just a joke, that you have to watch a counter when you round some edges, where other apps can do this instantly...)

There is nothing the SU team can do about the basic execution speed of Ruby. They do not develop the Ruby interpreter, they just embed it within SketchUp. Ruby is not designed as or advertised as a high-performance language.

I suppose there could be further optimizations in the SketchUp Ruby API (which is the gateway between Ruby code and underlying compiled SketchUp code). For example, new methods that hand off more bulk operations to the compiled library instead of using Ruby step-by-step logic. Other apps get their speed by having these operations done by compiled code, not by a scripting language such as Ruby.

Sophisticated programmers write the performance-critical parts of their extensions in compiled C/C++ code, which is much faster than Ruby. But they must still route their access to the SU model and library through the Ruby API bridge. They are compiled extensions to Ruby, not really compiled extension to SU itself. It isn't clear how much overhead that adds, but perhaps there could be a C/C++ API to bypass Ruby entirely (note: the existing SDK does not do so, it is for reading and writing SU files independent of the SU process).

I don't really understand your question, in particular the part about "a curve remains fixed". If it remains truly fixed, it will not reach the moved edges, and if it stretches to stay connected it is not "fixed".

If you are asking how to make the area larger without altering its shape, please take a look at the Scale tool. But if you are asking to have a second edge move in the y direction when you move a first edge in the x direction (ignoring the question above about the curve staying "fixed"), there is no built-in capability to do that in SketchUp. It would require an extension or perhaps a Dynamic Component to program this special behavior.

I don't remember whether the default is checked or unchecked, but that box has been in Model Info for a long time!

Thanks @pilou, that was an oversight that we hadn't fixed yet!