Rewriting the Outliner to enhance its usage

Hello All,

We certainly love SketchUp because of its basic but powerful user interface. But sometime we just need a little more to improve our workflow.

Although I think it might be easier to complete some tasks from the Outliner, I think I never really use it because it’s quite difficult to navigate through many instances.
This is the observation that pushed me to try to explore some practical improvements that can be integrated in the next release of OpenCutList extension.

  • Synchronized with the active path
  • Displaying materials applied on instances
  • Displaying tags applied on instances
  • Displaying common instance infos (instance, definition, description, url, …)
  • Highlighting instance in model on outliner mouse hover ?

Even though rewriting a feature like the outliner may seem simple, in practice it really isn’t. A lot of sub-feature are hidden under submenus or event observers…

Displaying an up to date model structure tree need to observe a lot of things.

So here is my first question :

What could be the best way to Observe model changes with performance in mind ?

Depending on the size of the model, it can be resource intensive to observe each entity, layer, material, no?

Thank you for your help.

2 Likes

Try to use single observer instances to “watch” multiple objects rather than instantiating a unique observer instance for every object.
The main reason to ever need a unique instance is if the observer object needs to keep state that is unique to the “watched” object. If this is not needed, then a single observer instance can suffice.

As an example, there is only ever one application. So there is no need for an AppObserver class. (A class is only needed if more than one instance is needed. So, this calls for a module to “watch” the application. The extension submodule itself most often can act as the AppObserver.)

Because there can be more than one model open on the Mac, it usually is best to have a unique instance of the ModelObserver for each model. But very often I find that it is best to use a hybrid observer and have the ModelObserver also act as the observer watching all of the model’s collection objects. (This avoids issues when state or data would be a “royal pain” trying to pass and share such resources. No passing between is needed because all the watching is done in the same hybrid observer class.)

Yes. But some collections have bulk callbacks that can be used for some discovery of new items.

I think the major challenge is not to bog down SketchUp during a geometric operation. How will your “tree” know when to pause and let SketchUp draw the new model objects. Ie, SketchUp’s native GUI will pause when Ruby coders use model.start_operation("My Geometry", true), but how would your “tree” interface know to pause until the operation was done?

If your interface was updating for every little model change, this might slow SketchUp down where the user can perceive it.

This would be the opposite of hovering with the Move tool ?

I think ThomThom has published an (old) example of highlighting instance bounding boxes using a tool. But now with the addition of Overlays a dedicated tool is no longer necessary. Just an activated overlay.
This has the benefit of not surprising the user when the active tool is changed on them. In other words, it enhances their workflow, without modifying the steps of their workflow.

2 Likes

Hi @DanRathbun,

Thank you for your answer.

Yes, that’s what I currently try.
So I will try to find a strategy to update only what need to be.

Currently OCL uses only one ModelObserver instance (through Singleton). This observer is added to all new or opened models from the AppObserver.

I’m not sur to see what you are talking about ?

Move tool change the selection. Yes here the goal would be to draw a bounding box or colorize faces (like OCL highlight tool do).

Yes, overlay would be an easier way to do it. But with 2 major problems : It doesn’t work on SketchUp 2017 and they are disabled by default :frowning: I’m not sur that a lot of user know how to enable them. It’s not a “plug and play” option :wink:

You can force an Overlay to be live using its #enabled= method.

1 Like

Yes, this is what I am doing for my Progress Overlay. It is only temporary whilst the operation is in progress and disables (disappears) when the job is complete. The class attaches itself to the model, enables, shows the progress (and optionally estimated completion time) then disables (after a chosen delay) when the work is done, and detaches itself from the model. (There is no interaction needed by the user to do with the Overlays panel. In fact, I have it closed most of the time. The user would only see it pop into the overlay list if they have that panel open and visible.)

1 Like

Thank you, I will investigate that :+1:

@DanRathbun, @slbaumgartner , here is my first try using Overlays to highlight entity under the mouse. Thank you for the tip.

2 Likes

It looks pretty good.

It also has the benefit of not modifying the model (changing object material assignments.)

1 Like

Few improvement Dan :wink:.

  • Now it highlights content faces instead of just drawing a translucent box. It’s easier to distinguish objects.
  • Dashed bounding box now ignore hidden objects
  • It displays the object name at the center of the bounding box
  • It paints in gray hidden objects

5 Likes