Continuing the discussion from Spacebar and escape key doesn’t work:
@TIG, @eneroth3
let’s talk here…
for returning to the ‘previous tool’, push and pop would need to work for ‘Ruby Tool’. which it doesn’t [currently]…
Sketchup.active_model.select_tool(nil) has been and is currently the best option…
john
(Moving my answer here.)
Sometimes you may want to PushPull after using the tool, sometimes you may want to draw a line and sometimes you may want to use the tool from another extension.
SketchUp doesn’t really have a concept of exiting a tool, just activate another one in its place. An ‘exit’ button in a custom Ruby tool isn’t really an exit button, but an “activate Select Tool” button, and we already have one of those as the largest key on our keyboard.
Adding a new button for activating Select tool is both redundant and inconsistent to the native tools. Ruby tools activating Select when the user presses Esc could be one of the reasons why some user confuses the two.
I’m not sure what the use case for returning to previous tool is, and whatever it is I don’t see how activating the select tool is a workaround for it.
SketchUp’s camera tools have the ability to interrupt other tools, and then give focus back to them, but in all other cases no native SketchUp tool activates a different tool. You use the shortcut or button for that other tool, independently of what tool you have active.
ok, e.g.
I have a ‘sphere tool’ and when it finished, you can make another sphere or change tools, that makes sense…
but many plugin tools do one task once, what state should they revert SU too?
it has to be the ‘previous tool’ or the ‘select tool’ because we have no idea what the ‘next tool’ might be…
I have never programmed the escape key to do anything, and can’t think of a single example where other people have…
john
In most cases when you think about it tools can allow for multiple draw actions. I can’t come up with any example of a tool that finishes at some point and then need to activate another tool. However I’ve seen several tools that swap to Select even though the user likely wanted to use it again.
I’m currently coding for a company that has decided to base their extension on the ancient house builder plugin, where the drawing tools just swapped into select after each action, rather than letting the user draw more walls, more windows, more doors etc.
I agree with @eneroth3 on this question. The existing design philosophy of the SketchUp GUI is that the user indicates when they want to change to another Tool by activating that other Tool. The selected Tool stays active until that happens. Tools aren’t supposed to hand-off control to each other or to provide an alternative mechanism for the user to change Tools. If a Tool quits of its own accord, there is indeed no way to know that the user intends to do next; any code-selected successor arrogantly steals choice from the user and creates a clash with how everything else works.
@john_drivenupthewall could you provide some examples of the “many plugin tools that do one task once”? I haven’t been think of any legitimate ones. The key may be the term “Tool”, which has a specific meaning in SketchUp: an object that takes control of the GUI and responds to the callbacks defined in the Tool interface. It is perfectly possible to wire a block of Ruby code (a “Command”) onto a menu or toolbar item, invoke it when that item is clicked by the user, and then return control to SketchUp, i.e. to the previously active Tool. So, in my thinking, a plugin that operates in that manner is not a Tool, doesn’t get control of the UI events, and doesn’t need to do anything when it exits.
How about ‘insert component’? Maybe it’s not technically a tool, but it qualifies as a single shot action.
After placing the component, the move tool is activated. However if the ESC key is pressed before the component is placed then the select tool is activated regardless of what tool was active before hand.
From this observation I would suggest that select tool is the ‘default tool’. This means that if my tool wants to exit and doesn’t necessarily need a specific tool active, activating the select tool would be the thing to do.
PlaceComponent appears to be an exception. Strictly technically it is a tool (fires the tool observer, listens to input etc) but most users probably wouldn’t think of it as a tool as you can’t activate it from a tool icon button. It also lacks an instructor and shares cursor with Move.
I find it quite inconsistent though how it activates Select tool from Esc. Axes tool, which is another of those very rare tools that just carry out one single action, re-activates the previous tool.
I don’t think this one tool is enough to say Select has some sort of separate status, as Paint Bucket, Eraser, Line, Freehand, Rectangle, Rotated Rectangle, Circle, Polygon, Arc, 2 Point Arc, 3 Point Arc, Pie, Move, PushPull, Rotate, FollowMe, Scale, Offset, tape Measure, Dimension, Proitractor, 2D Text, Axes, Orbit, Hand, Zoom, Zoom Window, Position Camera, Look Around, Walk, and Section Plane all treats Select just as any other tool.
Under what circumstances do you want your tool to be deactivated?
I completely missed this comment, probably as it was posted while I was writing my reply to the original post.
How many tools do really perform just one task, in the way PlaceComponent or Axes does? For all the tools I’ve seen that automatically activates Select after performing one task, it would have been more appropriate to reset the tool into its initial state, and let the user use it again, just like Rectangle, Rotate, Move etc. This is true for all drawing tools I can think of, whether they draw spheres, walls, windows, paints, sets UV mapping or swaps components.
In my experience unexperienced developers chose to force another tool to be activated, as they don’t know how to reset their tool into the original state, and instead tasks the user with pressing the button/shortcut again, to create a new clean tool object. I can confess on doing this myself as a beginner as it is the simplest thing to do from a coder perspective. However this is a discussion about UX.
Regarding Esc it fires the onCancel method with the reason parameter set to 0. I always use this to abort any operation started by the tool, reset its variables to the initial state and allow the user to use it anew, just as if it had just been activated.
I use it in Eneroth Solid Tools, Eneroth Align Face, Eneroth Relative Copy and Eneroth Component Replacer, just to mention a few.
My Building Creator Extension actually uses only SketchUp tools and I must confess I’ve actually never written a tool. In my Building Creator extension I have a Draw Porch command. This activates the rectangle tool to draw the floor plan. After the rectangle is drawn I automatically draw the porch from that, and select the finished component. After that I activate the select tool, because for this work flow it is more common to select something after drawing the porch, than the rare case of needing to immediately draw a second porch.
I agree that this should be the most common response of a tool.
I did have new users sometime tell me they couldn’t figure out how to get the line tool to ‘stop’. Simply press the big space bar and in their eyes the line tool ‘went away’. I’ve seen new users view the activation of the select tool as ‘quitting the drawing tool’.
For myself I still consider the select tool as a sort of default tool separate from drawing tools. Perhaps it’s because it’s the default tool when SketchUp starts.
Usually when a customers tells me they don’t want any color on their roof, it means they want white or gray, or sometimes even black. Neither of those are really correct because we do have a no color option which means unpainted (bare galvalume).
In SU it is impossible to have no tool activated (from a developer’s view point), but if a user would tell me ‘I don’t have any tool active’ (incorrect) I would assume (perhaps incorrectly?) that the select tool is active.
This sounds like a quite complicated and rather unorthodox implementation. Are you using tool observers to check when the rectangle is drawn? Such an approach would have to handle a lot of different edge cases, like the user changing their mind and not drawing a rectangle, or the user changing their mind and wanting to actually draw a rectangle, or the user wanting to use a rotated rectangle, or the user already having a rectangle they want to use.
In my experience a custom tool would be simpler to implement. The tool interface is a bit similar to the observer interface, but in my view easier to work with as you build something anew, rather than building into native functionality.
The absolutely simplest implementation for such a conversion would be to just have a button that converts the selected rectangle into a porch, similarly to how the Make Component button makes a component of the selection or delete erasing the selected entities.
I can agree Select is the default tool, given its selected on start. However, in many programs pressing Esc once in a drawing tool resets that tool to its initial state and pressing Esc again takes the user back and out of the toolt. In SketchUp going to Select isn’t a step back but a step to the side, into a different tool.
To most user there is no difference, but when extensions treat Select as a fundamentally different tool, it is inconsistent to how native tools treats Select.
Not that bad actually.
Yes.
Not really. To the user it acts just like a tool would. I add a grid and a note.
The only action that doesn’t act like a regular tool is when the user presses ESC. Currently it reverts to the ‘regular’ rectangle tool not in ‘porch drawing mode’. After this discussion I agree that it should stay in the porch drawing mode and simply reset to the original state. Once the porch is drawn the select tool is activated. I still feel for this use that is the correct behavior
Didn’t seem like it to me when I was writing the extension. The rectangle tool already does everything I want (like allowing measurements). All I needed to do was monitor tool state changes, and grab the rectangle to use as the base for the porch.
In this case that would only add another step. Draw the rectangle and then change it to a porch.
I do admit that a tool would be better because I could show the outline of the proposed porch in the tool while drawing the rectangle.
cool stuff …anyone “new” to developing ->(me) or SketchUp in general. That maybe following along, this will help explain the difference in ESC compaired to Space. Cool little video that helped open up some unknown(s) aspects in SketchUp.
SketchUp Skill Bulder: Space vs Esc
SketchUp Skill Bulder: Space vs Esc - YouTube
