Open or close the outliner windows

[dynamiqueagencement]

Hello everyone.

No need for a hidden component cleaning tool for Click-Cuisine 2.

The methods are more and more automated and the equipment is imported or deleted according to the needs of the user.

Importing many components and snapshots, if the “Outliner” window, is “not deployed”.

If the “Outliner” window is open, there is a loading time.

Is there a way to check the status of the “Outliner” window?

If the “Outliner” window is deployed:

1- The method must switch it to closed mode.

2 - Run the import code.

3 - Finally, deploy the “Outliner” window.

Thank you in advance for your help.

David

[DanRathbun]

UI.inspector_names

returns …

[ "Materials", "Components", "Styles", "Scenes", 
  "Shadows", "Layers", "SoftenEdges", "Outliner",
  "Instructor", "Fog", "MatchPhoto" ]

then …

UI.show_inspector("Outliner")

On Windows editions pre-v2016, calling this method when the Outliner was expanded would collapse it. This still may be true for the Mac editions.

But since the tray panels were implemented (on Windows) this method will only show or expand the Outliner panel. It will not roll it up (collapse it,) nor close it.

@dynamiqueagencement

Is there a way to check the status of the “Outliner” window?

ADD: And there has never been any API method (although we’ve requested) to query the UI to get whether the inspectors are open or closed.

(ping @tt_su)

[Aerilius]

Salut!

Do you already wrap your import method call into an operation, with UI updates disabled to improve performance?
See the second, boolean argument to Model#start_operation.

Apart from that, it seems not possible to hide “inspector windows”, only show them. Also it is rather something to avoid if your plugin has side effects affecting other unrelated parts of the program. Would users find it disrupting? Would you be able to restore inspectors exactly like they were, would the inspector’s state (size, position, focus, inserted text) be exactly restored?

[McGordon]

@DanRathbun

On Windows editions pre-v2016, calling this method when the Outliner was expanded would collapse it. This still may be true for the Mac editions.

Yes, it does collapse the Outliner on the Mac in SU 2018 on calling
UI.show_inspector("Outliner")

[DanRathbun]

@dynamiqueagencement

If the “Outliner” window is open, there is a loading time.

This is one reason why I (on Windows edition) have my “Outliner” panel in a “TREE” tray that autohides into the left margin.

[dynamiqueagencement]

@DanRathbun

UI.inspector_names

returns …

[ “Materials”, “Components”, “Styles”, “Scenes”,
“Shadows”, “Layers”, “SoftenEdges”, “Outliner”,
“Instructor”, “Fog”, “MatchPhoto” ]

then …

UI.show_inspector(“Outliner”)

Thank you Dan your solution works great!

@Aerilius

Do you already wrap your import method call into an operation, with UI updates disabled to improve performance?

I forgot to do it! Thank you for reminding me.

The import of sub-components is now fast even if the “Outline” window is open.

One small inconvenience is that the start_operation method can not undo an existing built-in tool selection in my method.

Example:

 mod = Sketchup.active_model
   mod.start_operation('selecttool', true)
	     mod.select_tool(DCInteractTool.new($dc_observers))
	       mod.commit_operation

This is a detail is without much consequence.

[dynamiqueagencement]

Same problem with this method:

 mod = Sketchup.active_model
   mod.start_operation('iconcheck', true)
     @@command.set_validation_proc{MF_CHECKED}
        mod.commit_operation

The import icon remains “CHECKED”, and can not go back to being status first with a rollback.

[DanRathbun]

@dynamiqueagencement

@@command.set_validation_proc{MF_CHECKED}

Do not put setup statements like this into an operation.

You should only need to set this up once when your plugin first loads.

# at top of plugin module
@@command_valid ||= MF_UNCHECKED

# among your methods
def command_checked?
  @@command_valid == MF_CHECKED
end

def command_toggle
  @@command_valid =( command_checked? ? MF_UNCHECKED : MF_CHECKED )
end

# at bottom of plugin in run once block
@@command.set_validation_proc { @@command_valid }

Now you can change the value of @@command_valid variable anytime, without needing to ever touch the proc object again, because the proc just evaluates the value of the variable.

You can also just call a method within the validation proc, and have the method evaluate differently depending on current situation.

BUT, validation procs for toolbar buttons get called alot so put as little into them as needed. Otherwise it can slow the UI redraw down. Validation porcs for menu commands only get evaluated when the menu is displayed, so their speed is not as critical.

[DanRathbun]

@dynamiqueagencement

One small inconvenience is that the start_operation method can not undo an existing built-in tool selection in my method.

Selecting a tool is not an edit to the model database.

You can always set the SelectionTool by passing nil:

mod.select_tool(nil)

---

In order to detect the undo, you’d need to implement a ModelObserver
Class: Sketchup::ModelObserver — SketchUp Ruby API Documentation
and reset the tool in the callback.

But it is likely more trouble than it is worth.

[tt_su]

@DanRathbun

ADD: And there has never been any API method (although we’ve requested) to query the UI to get whether the inspectors are open or closed.

(ping @tt_su)

This hasn’t been announced yet, but we’re experimenting with a public issue tracker on GitHub for our APIs. You can log bugs and feature requests here: GitHub - SketchUp/api-issue-tracker: Public issue tracker for the SketchUp and LayOut's APIs

[dynamiqueagencement]

Thank you Dan for your examples.
I will try your method for “CHECKED” my icons.