On a Mac, open both Entity Info and Materials windows. Select the entity of interest. Then click the little material tile in the Entity Info window. The corresponding material tile will be selected in the Materials window. Hover the cursor over that tile and you will get a popup with the material's name.

As TIG wrote, the Mac Materials editor is loaded with quirks that make it more confusing to use than the Windows one.

Except that there appears to be a little step where the chamfer meets the ends, you could build a sort of sled that holds the leg at 45 degrees and run it past an ordinary rabbet bit. If that step is there you'd have to stop a bit short of the end, move over a bit for the step, do the end, and then clean up the little step with a chisel.

That's a somewhat ironic error from a line that is trying to tell you that the plugin requires SU 2016 or later, but the code to show that message tries to use a Language Handler object (LH) that is only initialized if you already have 2016 or later! If your profile is correct and you are running SketchUp v7 or if, as your post says you are running SU 2015, you can't use this extension.

To load a Ruby file SketchUp processes the source through 'eval'. That message is saying that some extension's Ruby file is so severely damaged that eval gave up. So, as TIG wrote, you will have to track down the culprit among your plugins/extensions.

What you are seeing is "bleed through", which is a variety of "z-fighting". That is, when the OpenGL renderer can't distinguish between the distance to two surfaces or an edge and a surface, it tries to display both. For surfaces this causes a flashing effect as you orbit the model. For edges, it causes them to show through the surface.

There are two workarounds commonly used.

One you have already tried: add some thickness to the surface so that the OpenGL renderer detects it at a different distance than the edge. And, as you have seen, "different" depends on how far from the surface your view's camera is placed. When the camera is farther away, the separation must be greater to overcome the bleed through. Sometimes the modeled surface really ought to have thickness to correspond to a real object, but other times the amount of thickness to overcome bleedthrough is not reasonable.

The other workaround is to hide the edges that are bleeding through. Since hidden is one of the attributes that can be saved with a scene, you can use different scenes when you want vs do not want the edges to show, e.g. when the components with the edges are visible vs when they are behind something else.

Start with this page. Scroll down to the bottom and select mac. Then the links will lead you to Mac-specific versions of the instructions about materials.

https://help.sketchup.com/en/article/3000112

BTW, the Mac materials editor is different from the Windows one and, in the eyes of many of us, far more confusing and difficult to use.

Trimble is already working with other sources to provide terrain and overhead images when the Google API is discontinued. Time will tell how the coverage and quality compare with Google Earth.

On the Mac, it is command-key chords that are pre-assigned by the GUI and can't be used as SketchUp shortcuts.

Two thoughts:

First, the code you show isn't modifying SU's DCFunctionsV1, it is creating a new class of that name within the M123::M123abc module namespace.

Second, what makes you think that just defining atan2 within the DCFunctionsV1 class will make that formula available for use in DC's? That assumes a lot about how the DC class is programmed (which isn't documented).

To use layers or simple hiding, your "outliners" should be groups or components. If they are edges and faces, associating them with hidden layers is almost certain to cause issues because loose edges and faces on hidden layers or simply hidden still interact with other loose edges and faces!

I don't know what an "outliner" is, but that probably doesn't matter. On the Scenes window, check that the scenes are set to save "Hidden Geometry". Then hide/unhide the desired parts on a scene, right-click the scene's tab and select "Update" before switching to the other scene.

That indeed sounds very strange!

You are not allowed to create your own shortcuts involving the command key (and so far as I know, never have been). This is because the command key chords are hard-wired into the SketchUp menus, not managed via the user shortcuts system. So it is quite unexpected that anything could change how they work. If you open the Edit menu, what does it show as the keyboard shortcuts for the Make Component and Make Group items?

I use a Mac (macOS Sierra 10.12.3, SU 2017 Pro M2, Xcode 8.2.1) and I can't reproduce this issue. That doesn't mean it wasn't triggered by the update, but it depends on something specific to your system. I have no clue what, though.

@bflmpsvz said:

I usually select only faces which really need to be intersected (and use Intersect Faces - With Selection). The unwanted "hiden" lines can usually be simply deleted, so I use Eraser for it. This is not perfect solution, but usually good enough.

Sometimes SketchUp creates hidden edges as part of its "auto-fold" behavior and then fails to erase them when it turns out the surface actually stayed planar. In such cases you can indeed erase them. An intersect operation may help SketchUp re-examine whether edges actually cut faces, especially the edges of a smaller face inset in a larger one.

But if you erase an edge and adjacent faces also vanish it is a sign that the corners are no longer planar so SketchUp had to use triangles to cover them. No operation other than correcting the vertices to planar can heal this situation.

As Dave said, you haven't given us much SketchUp-specific info to go on, which leaves open the possibility that SU is a victim of some other problem with your system. For example, some other process that is hogging memory, CPU, or disk. Or maybe issues with a network connection. Or maybe something has decreased the mouse "speed"...

@jim said:

It's not you. Dynamic Component programming is basically undocumented. All you can do is look at other peoples examples. Not to mention there are a number of bugs that occur even if you are doing everything correctly. Overall, it's a frustrating experience.

Amen! But let's separate Ruby from Dynamic Components. Although the DC mechanism is implemented in (encrypted) Ruby, developing DC's does not involve Ruby per se. It is done via a set of GUI panels without any Ruby source file coding at all!

Someone with more insight than me could correct this, but I have the impression that the DC's were a pet project of a single person who left the development team some time ago and Trimble has not seen fit to devote anyone to maintenance of DCs since. Personally, I found the lack of documentation so severe and the myriad quirks and bugs so frustrating that I long ago gave up even attempting to develop DCs!

For a long time the documentation of the Ruby API has also been deficient, full of errors and sloppy or lazy examples. At least the Trimble team is giving attention to this aspect, including a new YARD-based technique for generating the API docs and a GitHub repository where people can propose corrections.

My own Ruby API coding efforts are motivated by two things:

Sometimes I find a seemingly simple operation that core SketchUp simply doesn't provide and that other existing plugins don't implement the way I would prefer (typically because they throw in extra stuff I didn't want. I prefer KISS). So I write my own.

I'm also fascinated by the defective models that people bring to this and the official SketchUp forum asking for help. I write Ruby analysis tools for my own use to probe into the model structure and understand what went wrong. Sometimes these tools help me to repair a broken model, and sometimes they help me to identify bugs in SketchUp itself. But they always help me to gain a deeper understanding of how SketchUp works.

The Ruby API has support for the required operation, so if you can't find one it would be very easy to write a plugin that creates a toolbar button or menu item that saves to (e.g.) SU version 7. The key statement, paraphrased directly from the API docs, is just:

status = Sketchup.active_model.save("", Sketchup::Model::VERSION_7)

Yes, Gerrit, I tried your model. As saved, inferencing on the green axis indeed fails. But if I orbit so that the axis isn't so straight back in the view, green axis inferencing works fine. Having the green axis oriented too close to the "into the screen direction" in perspective seems to induce the problem, and I was suggesting that maybe this direction causes the inference engine to struggle trying to infer how far back in the "into the screen direction" the cursor is marking in empty space. I should emphasize that my explanation was only a theory - without access to the SketchUp code I'm just guessing based on symptoms.

In the images @Wo3Dan showed, the intersection of the Green axis vanishing point with the horizon seems to be visible. But if you ponder a moment, you must realize that this point is infinitely far away and can never actually be seen! The ratio of pixel to distance (foreshortening) thus becomes infinite as you move up the view away from the origin! I think this makes it impossible for the inference engine to determine where you are intending the cursor to be in the model, and it gives up.

It works for me on mid-2012 MBP retina, SU 2017, OS X 10.12.3.