How can I permanently close the extension windows?

Every time I launch SketchUp, the windows of the extensions keep appearing. I close them, but on the next launch, they reappear. Having to close these windows every time I launch SketchUp is extremely annoying. Is there a way to close them permanently?

Снимок экрана 2024-03-02 в 02.33.07

macOS 12.7.3
SketchUp Pro 23

Those are toolbar buttons, not windows. Disabled the extensions in the Extension manager and only enable them when you need them.

@DaveR That’s not a solution for me. I need to use the Keyshot extension regularly.
It seems like an oversight on the part of the SketchUp developers.

It’s an oversight by the author of the extension. Contact them and ask them to make an edit to their extension code. Until then you can always enable it when you need it. Or move it outside the model space so it’s not in your way.

That’s not how good software should function. It definitely should be fixed by the SketchUp developers.

@DaveR How can I get in touch with them? Is there any form to submit a bug report to fix this issue for all extension once and for all?

No there isn’t, it’s annoying for me as well.

1 Like

@francisquitof What specific extension windows are you having problems with?

Clothworks, architectures, Vray, helix along curve, sketch plus and others that I don’t remember, I disabled them and enable them only when I use them, the only one I always keep enabled is VRay cause I use it frequently.
On windows by some reason after a few launches the toolbars don’t appear, but on Mac it doesn’t happen.

1 Like

@francisquitof That’s too many! So wouldn’t you want this issue to be fixed once and for all?

Yes but it’s up to the developers. And as I said, I’ve disabled them so they don’t appear on my workspace anymore.

1 Like

By the way, double posts are against forum policy

no need to ask twice in two locations, you’ll only get the same answers twice.

There are two solutions to this problem:

Have the SketchUp developers fix this issue by making SketchUp remember both the position and the state of the extension toolbars (enabled/disabled).

Have the Clothworks extension developers fix this issue with their extension.
Have the Architectures extension developers fix this issue with their extension.
Have the Vray extension developers fix this issue with their extension.
Have the Helix Along Curve extension developers fix this issue with their extension.
Have the Sketch Plus extension developers fix this issue with their extension.
Have the Keyshot extension developers fix this issue with their extension.
Have the developers of every other extension fix this issue with their extension.

Can’t you see that the first option is more reasonable and the second one isn’t feasible at all?

ok, that’s a new one, usually you would have gotten the same answer twice, I sure didn’t expect you to give basically the same answer to the same person in two separate thread within a 15 min window

@ateliernab
Those were replies to different posts. You need be more attentive.

This is the very root of the problem. The app can remember the position of the extension toolbar but not its state (enabled/disabled) for some reason.

I discovered that post later on.

Your understanding of the relationship between SketchUp and extensions is incorrect. Every extension is essentially its own stand alone application.SketchUp simply opens up the door for ruby code to alter and interact with the base program. SketchUp has no control over what individual programmers do, Sketchup does not oversee the extensions or have control over what the code of an extension does.
Most extension developers write decent code and remember to save the state of their toolbars so that state (open or closed) persists when restarting SketchUp. Some don’t, either through ignorance or laziness and it’s annoying, I agree. But that is a problem of that extension programmer, they should write better code like the majority of extension developers do.

SketchUp could solve this problem, by closing the ruby API, and allowing no extensions to interact with their programming at all. Indeed if you uninstall all your extensions you will see that all the windows and toolbars that are a part of native SketchUp function as expected. I don’t think this is a solution anybody wants, it would be punishing us all for the sake of avoiding a few annoying toolbars.

If you don’t like the way an application behaves on your computer, do you blame Apple? Apple should do a better job of policing Microsoft because Word for Mac has bugs? No we blame the app developer for their buggy software. This is no different, every extension is it’s own program, so if you download and install a program (extension) that you don’t like then uninstall it or ask that developer to fix it.

SketchUp can only shut the door and let nobody in, or throw open the door and let people play. Even though it’s imperfect I really prefer latter and am grateful to SketchUp for keeping the door open.

1 Like

All of that list are extensions you pay for somewhere other than in Extension Warehouse, which makes testing some of them a bit more expensive for me. But, I do own a Clothworks license, and I can use Vray as well. So I tested those two…

In the case of Vray, I closed three of the panels, and moved the other one. When I reopened SketchUp the three I had closed were still closed, and the last one remembered its position. Next I tried closing that one as well, and reopening SketchUp showed it was closed now.

I believe the preferences are set when you close SketchUp normally, so I did a test by showing one of the Vray panels, and doing a force-quit. That panel was not open when SketchUp opened up again. I opened a couple of Vray panels, quit normally, reopened SketchUp (they were both open again), then I closed both of them and force-quit again. Reopening SketchUp had both visible again, even though I had hidden them

At least as far as Vray goes, the behavior is as expected. Close or show panels you want, then quit normally, and the panels should be back how you wanted them. If SketchUp or macOS crashes, the changes you made in the last session will be lost.

Clothworks was different. I could try to hide that repeatedly, and it would show up next time. @Anton_S does post in the forum sometimes (well, very occasionally he does!), maybe he can say whether Clothworks has a preference I am not seeing.

I have an internal testing extension, written by one of the most famous of extension developers. It also reopens every time. I can ask the extension developer (who works for SketchUp) whether it’s down to the individual extension to maintain its visibility, or if SketchUp should have done that.

1 Like

This has gone too far in ignorance despite attempts to explain. For the record:

  • The code to create a toolbar is processed each time SketchUp loads the extension during startup. The extension developer writes this code.
  • The state of the toolbar is saved when SketchUp closes normally. The extension does not need to do anything to make this happen. If SketchUp crashes, it doesn’t get a chance to save the current toolbar state. If there was a previously saved state, that will be used the next time SketchUp starts, regardless of how it was set during the crashed session.
  • If the code says toolbar.restore it is opened at the same size and location as was recorded the last time SketchUp closed normally.
  • If the code says toolbar.open, the toolbar will open as SketchUp starts regardless of how the user left it last time.
  • If the code says toolbar.hide, the toolbar won’t be open when SketchUp starts, regardless of how the user left it last time.
  • If the code just creates the toolbar and says nothing about what to do with it, I believe it will be opened, regardless of how the user left it last time.

The obvious point is that the SketchUp Ruby API provides all the control the extension developer needs to make the toolbar behave or misbehave. It is up to the developer to tell SketchUp which way it wants to happen. Having SketchUp mandate restore, as implied by many of these posts, would take away some of the developer’s freedom of choice.

4 Likes