Disabling extensions

I have been using an extension called Edit Flag which warns you when you open a component for editing. It’s useful but a bit irritating because it forces you to click inside the component before you can start editing it. So I thought I would try living without it, relying on the Entity Info box instead. In case I wanted to use it in future, I disabled it in the Extension Manager and applied changes. Now, my expectation was that it would no longer work unless I re-enabled it. I don’t know why I jumped to such a hasty conclusion. Anyway, I was wrong. Disabling it doesn’t…what’s the word?..disable. Anyone understand why? Or what the disable toggle is for?

Obviously, I can simply get rid of the extension and reload it if I want it back later. But I’m a bit old school and like things to work the way you reasonably expect them to. After all, one of SU’s main USPs is intuitiveness.

Whilst on this roll, I wonder if anyone finds, like me, that the way extensions are managed in SU is a bit confusing. Some appear under the Extensions menu, others are dotted around elsewhere. And you might expect all extension to show up in the EM, but they don’t. I have Kerythea Exporter under extensions but not in the EM.

And here’s a suggestion. It can be difficult to know what extension you are using. Unless they are in the Extensions menu there is no way to distinguish them from native tools. Could they be distinguished by the simple expedient of using a different coloured text?

You might find that you need to restart SU before the disabling takes effect. Did you do that already?

It is up to the Extension author to decide where the extension should appear.

It makes sense, sometimes (at least ( think so) to place it elsewhere than on the Extensions menu. For example, I’ve written a small number of extensions (with help), one of which is placed on the Draw menu because, well, it is used to Draw - in my case, 3D Shapes.

Another, Angular Dimension 2, is placed on the Tools menu, along with the native Dimension tool.

Does that matter? In some ways, the more an extension behaves like a native tool, the better integrated it will feel, one could argue.

You can’t do that with the current Ruby API for the Menu class. But perhaps it could be added?

I haven’t but it did occur to me. However, you are also asked to Apply Changes, suggesting strongly that you could expect it to take immediate effect, just as most extensions can be used as soon as they have been installed, without restart.

Indeed. I guess it’s one of the things about software like this that works by allowing bolt ons that are not made to follow a specific protocol. If it were possible, distinguishing non-native tools would do the trick for me. I appreciate that it might mean an amendment to the options under the Ruby API.

I wish there were UX guidlines available to solve a number of these issues.

I strongly believe most extensions should be in the Extension menu, but with some rare exceptions. A simple script that adds and extra entry for toggling text visibility makes sense to have next to View > Axes, View > Hidden Objects etc. Extensions with multiple entries like add object, object properties, help etc, should IMO be wrapped in a submenu in Extensions.

Unfortunately SketchUp doesn’t unload extensions right away when disabled, but extension authors could listen for the extension being disabled and use this to stop the observers listening for model changes. Ideally SketchUp should remove menu entries and unload the extension code.

Kertkythea missing from EM suggests it’s merely a plugin, not an extension which is a kind of plugin that registers its existence when loaded. By now I think every SketchUp plugin should be an extension, and for end users these two terms should be possible to use interchangeably if extension … eh, plugin … developers would get it right.

Regarding coloring the menu entries for extension I think that might look rather awful, but if extension names are prepended by the author name it’s easy to distinguish them without adding as much noise to the UI. Often developers also have different styles, and changes are you remember what an extension looks and feels like even if you’ve forgotten the name (did it have the boxy gray settings bar at the top of the model viewport? Then it’s a Fredo extension).

If it’s gray, then it’s probably not my plugins…

1 Like