Is it worth using Sketchup::Tools stack to decompose a complex scenario? For exampe, I need to define (receive from the user) a virtual box. Thus, the user can enter the parameters of the box from the VCB or draw it by defining the base rectangle and the height of the box. Are the right way to divide this logic into two classes of tools, one for determining the box and another for the main plugin logic?
Generally, NO. The tool stack is just a FILO stack collection.
It’s only good for determining the active tool id, or popping a custom Ruby tool off the stack to reactivate the previous tool.
Re the Sketchup::ToolsObserver …
Since the 2016 overhaul, many of the native tools transparently do all their steps within a single operation, and only afterward dump their subtasks to the observer engine. So all of a native tool’s tool states are over and done with by the time any of our observer callback methods are called.
The best paradigm is to code a custom Ruby tool.
There is a simple Cube extension example by the SketchUp Extensibility Team:
No, this would likely confuse the user. Better just to use a branching if statement and handle either case within the tool class interface. Such if statements often check an instance state variable such as @state where it is 0 or 1 when first activated and no points have been clicked.
maybe this code will help me explain what I meant.
test_tools_stack.rb (4.2 KB)
It’s a very bold statement, , if I understood it correctly
No my statement is direct and made in a matter of fact manner. No boldness implied.
I encourage you to examine the examples previously linked in the tutorials repository.
Thank you for your answers