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
I don’t remember anymore, but it seems that this record was made at the moment when I was using the SU tools stack to implement the scenario of this tool. And although this turned out to be not the best solution, I am still confident that even if it’s possible to implement such logic using branching operators, this code will be impossible to test (maybe I haven’t learned Zen.). I think I’ve found a good enough solution to implement such complex scenarios, and if anyone is interested, I’ll be happy to share it.
1 Like
Hello @mike09,
Interesting idea to draw cabinet.
1 Like
Dan was trying to point out that your approach - while not impossible to implement and execute - is unconventional and does not follow the recommended and established methods of the Tools used to be in Sketchup.
Anyway, the recording is really interesting, especially the content in the upper right corner… 
Yes, I use it, thank you ). And special thanks for the open source and to everyone who shares their solutions.
1 Like
I tried to solve this problem and I want to share what I got. One of the reasons to do this is that my solution
The code is an sketches or draft and is interesting more from the point of view of the solutions used than practical value. I would be very interested to hear your opinion on this.
Happy New Year! Peace and happiness!
parametric.rbz (16.8 KB)
Okay here goes …
(1) Every coders must use a UNIQUE top-level namespace module.
The module name Parametric is not unique.
It is suggested that you use your company or name as your namespace module.
All extensions would be submodules of your namespace module.
Your extension registrar file and extension subfolder should follow the module naming.
Please read this:
(2) NEVER modify Ruby Base classes or SketchUp API classes!
SketchUp Ruby is a shared environment. Making modifications can cause other extensions to fail.
Although comparison within SketchUp’s point and vector tolerance is beneficial, you should either use an method within your custom modules or classes to do the comparison, so that there is no possible clash with the code of other extensions.
An alternative is to use a Ruby Refinement, thus …
module Mike09
module TransformationComparsion
refine ::Geom::Transformation do
def ==(transformation)
transformation.instance_of?(::Geom::Transformation) &&
[self.origin, self.xaxis, self.yaxis, self.zaxis] ==
[transformation.origin, transformation.xaxis,
transformation.yaxis, transformation.zaxis]
end
end
end
end
… and in your code file:
module Mike09
module Parametric
require_relative 'refinements/transformation'
using ::Mike09::TransformationComparsion
# The modification of ::Geom::Transformation can be used here
# and it will not interfere with any other code files.
end
end
REF:
(3) In the tools.rb file:
These keycodes are only valid for MS Windows. You need conditional assignment:
if Sketchup.platform == :platform_win
VK_TAB = 9
VK_ESCAPE = 27
else
VK_TAB = 48
VK_ESCAPE = 35
end
(4) Later on if you wish to encrypt the files as rbe, then you cannot use require_relative or the global require. You’ll need to use Sketchup.require instead.
2 Likes
Admittedly, I was expecting to hear something on the topic, nevertheless, Dan, thank you for your comments.
I am not aware of any plugins that use Parametric as the root. Please let me know if this name is already in use.
I’m not sure I understood you correctly. Perhaps you have overlooked that the comparison method is missing from the Transformation initially. Or by modify, did you mean any class opening?
Thanks for this clarification.
I’ll keep that in mind.
I have not. Nor does it matter.
DO NOT directly modify ANY shared classes or modules, even if you find OLD examples that did so. (Such examples were written before Ruby Refinements were invented for Ruby 2.0 and higher.)
SketchUp Ruby is a SHARED environment. Use a Ruby refinement (that only your code can “see”) OR use a method local to your code that passes in a transformation argument.
(1) It does not matter if the word is in use, … it is a common word that cannot be considered unique to YOU. Using a top-level uniquified namespace module for ALL your extension submodules and libraries is required in a shared environment. Making one based upon your forum member name, your real name or your company name, is the easiest way to generate a unique namespace.
(2) Further, I think (if memory serves) that it may have already been used by several example extensions by the SketchUp Extensibility Team. Even these handful of extensions ended up having different versions of the Parametric object which causes confusion as they clash.
I believe some extension developers tried to use this example Parametric library in their own extensions and ran into this clashing issue. The solution for them (like YOU) is to wrap the Parametric object WITHIN a uniquely namespaced library or extension submodule.
AGAIN … I refer you to …
1 Like
UPDATE. There are currently issues with onKeyDown and onKeyUp in the abstract Tool class for the MacOS platform that makes my suggestion unreliable with respect to the TAB key. Using a 9 keycode may actually work in older release of SU on Mac. The latest 26.1 release has major problems with TAB.
MiniTest, JSON and PP (aka PrettyPrint) are Ruby CORE libraries, and yes they make additions to core classes.
The SketchUp API’s ::Geom module should not be mixed into Object or Kernel. It is not on my machine.
I will keep your comments in mind. Maybe someday I’ll accept them and switch to the Light Side. In the meantime… I love Ruby because he lets me do things like that
And let’s be honest: Ruby CORE hierarchy is BasicObject - Kernel - Object
You may do want you wish on your own machine, but do not expect to have such code pass review in SketchUp’s Extension Warehouse.
Mikhail, you can modify the classes your code uses but you need to use Ruby Refinements so that the mods do not affect anyone else’s code.
Do you realize what would happen if everyone was directly modifying core or API classes?
It would be chaos.