Startup Event (end of Sketchup load sequence)

[Fredosixx]

When Sketchup starts up, the sequence implies to load plugins, display toolbars, update the state of icons, etc... and finally give the control to the users for clicks and keys.

Some plugins may have to perform tasks right at startup, like displaying a notification (or other initialization). The issue is that they don't know when the user gets the control (i.e. UI responsive). If you display a notification with a button and Sketchup is still busy with its startup sequence, then clicking on the button would do nothing else that to show the spinning wheel (and possibly 'Program not responding") until it gets idle. This may create frustration.

Currently there is no way to know when Sketchup is ready at UI level.

REQUEST: mechanism to advise or check when Sketchup has finished its startup sequence.

I let the Sketchup developers to choose the mechanism: could be a registration of callback, an observer, ....

Note: By the way, I noticed that the update of toolbars and icon state is what takes the more time (see video below)

[DanRathbun]

I already formally requested this like maybe 8 years ago. We can assume the idea has been rejected.

The workaround is to use an AppObserver and a #expectsStartupModelNotifications callback to assume that the model object is ready for User interaction.

We also discussed this in the public forum I think, and over at SketchUcation as well. (I remember Rich Morin was involved in the conversation as he was wanting to do batch mode use of SketchUp Ruby scripts.)

• forums.sketchup: How to run SketchUp extensions? (post 10)

[thomthom]

Note: By the way, I noticed that the update of toolbars and icon state is what takes the more time (see video below)

Yes, it's been a suspicion of mine as well that toolbars adds notifiable time to the startup time.

Some plugins may have to perform tasks right at startup, like displaying a notification (or other initialization).

Do you have some examples of what such notifications would be? In general it wouldn't be a great experience if extensions fight over displaying information at startup. Would be better to defer until the extension is interacted with.

Initialization is easier to understand. (But can you provide some examples here as well?)

[Fredosixx]

On the toolbars,

• I am wondering what Sketchup is doing under the hood. As you see, it at least executes the validation_proc of commands, but we see this visually, whereas these validation_proc take less than 0.001 s to execute (at least mine). Sketchup also seems to do some stuff for Sketchup commands (like the Shadow sliders). Would be good to know what all this activity is dealing with.

On the notifications

• A typical example is when a plugin is not compatible with the current SU version. Another one is when some plugins are outdated (my reminder of Check Plugins for Update).
• Whether notification or hard message box, they may appear before the UI is ready to receive inputs. So, the user would click on a button and nothing would happen right away. This may be frustrating...

@Dan: Unless I am wrong, #expectsStartupModelNotifications is a workaround dedicated to an old problem where no observer callback where triggered for the initial model loaded at SU startup. The doc says:

The #expectsStartupModelNotifications method is called to determine if the observer expects to receive #onNewModel and #onOpenModel calls for the models that are created or opened at SketchUp startup. This includes the empty initial model, a model opened via command line arguments, or auto-restored models on Mac OS X.

So not related to the startup readiness event, unless if, by chance, this callback is triggered after Sketchup is ready. I will try.... EDIT: checked it and it does not help. The callback expectsStartupModelNotifications is triggered BEFORE the plugin icons are even shown!

[DanRathbun]

So not related to the startup readiness event, ...

On the contrary, SketchUp cannot be ready for user input until a valid model object is loaded. This happens (or did) at different times on the Mac and Windows. On Windows a valid model was loaded before extensions were loaded. On the Mac, extensions were loaded before a valid model (or models) were loaded. (@thomthom Can you see if this still the case.)

We have / had issues with tracking the model object between the platforms, and often result in instead testing the id of the model's definitions collection object.

Anyway ... we used to run UI.start_timer block that kept checking for model.valid? && model.definitions.valid? etc. Some coders also identified the last alphabetical rb file in the "Plugins" folder and would check $LOADED_FEATURES for it's path so they'd know that all the extension registrar files had been processed.

Fredo, don't get me wrong. I'd love for a API boolean state exposure to signal the completion of extension loading (Sketchup::ExtensionsManager#start_cycle_complete?) and also perhaps a user interaction ready (UI::ready_state?).

---

I can no longer find my API feature request as it likely was attached to an old SketchUp alpha cycle. @thomthom It used a suggested method name like "startup_complete" or similar. Can you see if you can find it and if an internal Jira issue was created (and when) ?

[Fredosixx]

---

Anyway ... we used to run UI.start_timer block that kept checking for model.valid? && model.definitions.valid? etc.

That won't work either to signal the end of the startup cycle. Best proof is that, during their own load cycle, my plugins use Sketchup.active_model successfully, meaning that it is valid?.

Last plugin load is also of limited usage, because the real time gap is after ruby files are loaded (as shown in the video).

Let's have a Sketchup developer have a look at how the startup sequence is structured and advise.

[DanRathbun]

Your points are well taken. I agree no workaround is really adequate. They are all merely "hacks".

I guess my point is that they already did "look at this" and did not give us the ready state boolean method nor an AppObserver#onReadyState observer callback.

I'd really like Thomas or whomever to take another look.

There should be internal notes from the last time time this was contemplated. I would be interested to know why it was rejected back then, and then we could discuss whether the same negative factors still apply to blocking implementing it now.

---

Re notifications ... there are several open issues that need to be fixed. (Ie, especially duration of display time.)

Are startup cycle notifications queued up and displayed after the GUI is completely built and drawn ? If not, perhaps they should be. Thoughts ?

[thomthom]

Re: Toolbars

I am wondering what Sketchup is doing under the hood.

I'm not sure exactly what the extension toolbars are doing during startup. That's some old code that haven't been touched in years. I want to find out though.

As you see, it at least executes the validation_proc of commands, but we see this visually, whereas these validation_proc take less than 0.001 s to execute (at least mine

Yea, on Windows the validation procs execute very frequently. So when you have a few toolbar buttons that can add up. What often happens in these validation procs are checks for what's in the selection. This could cause performance problems when the selection is very large and its iterating everything in the selection. This is something I wanted to add to a Performance section in the API docs.

Sketchup also seems to do some stuff for Sketchup commands (like the Shadow sliders). Would be good to know what all this activity is dealing with. Not sure I understand what you describe here. Is "Sketchup commands" UI::Command? And do you see some unexpected behaviour when interacting the the Shadow sliders?

[thomthom]

Re: Notifications

A typical example is when a plugin is not compatible with the current SU version. Another one is when some plugins are outdated (my reminder of Check Plugins for Update).

In both these cases I would recommend not popping up a message upon startup. Imagine if every extension did this and a user has 10, 20, 50 extensions. Instead I would defer them to when the user first interact with the extension. The user might not even intend to interact with your extension at all that session, but be in a rush for something else - in which case updates or incompatibility isn't relevant for the user. The user can address that when they have a need for the extension.

Whether notification or hard message box, they may appear before the UI is ready to receive inputs. So, the user would click on a button and nothing would happen right away. This may be frustrating...

Yes. I would strongly discourage modal dialogs during startup for any reason. As for notifications, I think it would make sense for SketchUp itself to queue these until the app has fully started.

expectsStartupModelNotifications was added to ensure the model observer was triggered for models opened/created before Ruby was initialized.

I can no longer find my API feature request as it likely was attached to an old SketchUp alpha cycle. @thomthom It used a suggested method name like "startup_complete" or similar. Can you see if you can find it and if an internal Jira issue was created (and when) ?

I wasn't able to find anything in the internal tracker matching startup_complete. Any other terms that might have been used?

[Fredosixx]

@thomthom

1) On notifications at startup, I use it for notifying users of incompatibility. A classical case is an extension (say RoundCorner v1.8a) requiring a specific library version (say LibFredo6 v10.9). If there is not visual indication of that requirement, then RoundCorner would not appear anywhere in Sketchup. So there is no 'first interaction" with the plugin. I recently opted for UI::Notification with a 'Forget' button, so that the message can be discarded for all future startups. And I group all messages related to my plugins in a single notification.

2) For toolbar set up, it is obvious that Sketchup does a lot more than executing validation_proc of commands. It would not be visually visible as on my video example, noting that in general, the model selection is empty at startup. So there must be something else.

3) For Shadow toolbar, I noticed that it is repainted at the end of the process. So, here too, Sketchup is checking something under the cover.

[thomthom]

1) I do something similar for TT_Lib, but I use a non-modal dialog so it doesn't block SU. I like your "Forget" idea, I should have that for my dialog as well. (Though I'm migrating away from TT_Lib these days.)

2) Yea, for startup I suspect it's related to the UI framework as it's dynamically building the toolbars. Might be that it's updating the UI unnecessarily while building everything. (But that's just a wild guess, will find out more when I dig into it.)

[DanRathbun]

I wasn't able to find anything in the internal tracker matching startup_complete. Any other terms that might have been used?

We might have talked about an AppObserver#onReadyState observer callback.

[DanRathbun]

2) Yea, for startup I suspect it's related to the UI framework as it's dynamically building the toolbars.

SketchUp also has to load the button image files, and size them if they are raster, maybe even if vector, ... depending upon the UI display scaling and the small/large SU button size setting.

But I wonder if the UI setup core code could be reorganized to defer the button image processing to later ? It could (perhaps) put all the toolbars with blank buttons in place, and fill them in with images as time permits later. (Ie doing more important things like getting the model and extensions fully loaded.)

At the very least perhaps defer the attachment of validation procs till last ?

[Fredosixx]

I am not worried at the construction and display of the toolbars. This is reasonably fast and there is a visual feedback to the user.

I am more concerned with the subsequent phase, where Sketchup sets the state of icons (gray-out, selected, ...). This is very slow, and on the video, second part, we can almost see each icons state being set. The visual feedback is less visible, and the user may be confused. What is exactly happening during this second phase? It cannot be the validation_proc, because they are already loaded and have individual sub-millisecond response times. So what the hell is Sketchup doing?

[DanRathbun]

Initialization is easier to understand. (But can you provide some examples here as well?)

The following forum topic is another real world scenario where an extension needs to know when the startup cycle is complete so as not to cause the blocking of other extension loading whilst looking up data online:

https://forums.sketchup.com/t/async-background-job-in-sketchup/179179

[DanRathbun]

@Fredosixx Has the implementation of the Sketchup::AppObserver#onExtensionsLoaded callback method for the v2022.0 released solved this open issue for you?