When using Rotate Tool, in onToolStateChanged, state never equals 1. Bug?

Developers Ruby API
, ,
1

When rotating a shape, the tool is never active (state == 1).
For this logging call in onToolStateChanged

log "onToolStateChanged: #{tool_name.to_s} #{tool_id} #{state}"

I get the following output when using the rotate tool. ( The tool is already selected) :

SUMM: onToolStateChanged: RotateTool 21129 0
SUMM: onToolStateChanged: RotateTool 21129 0
2

The API says:

The actual state that is returned is an internal number that varies tool to tool.

That is a bit vague. To be more precise. There is no standard whatsoever that all the internal “native” tools adhere to.

It certainly would be nice. Usually for most tools the initial state is 0, and when the tool is reset (normally by pressing ESC key.)

Some would argue it’s not a bug because it never had any state changes. But logging it as a bug is the best way to eventually get it fixed.

Problem is they are unlikely to stay the same, forever. Or at least unlikely to stay integers.
If a new feature is added, in between two states, say in between 1 and 2, then the obvious choice rather than change all the state numbers (and break a bunch of plugins,) is to make the new state be 1.5, (or similar.)

So, basically, even though the API has observers to see when tool states change, they have not given the feature “much love.” It is like “painting themselves into a corner” for future tool expansion.

I would recommend the API switch to symbol state names, instead of sequential integers.

Ie, for the RotateTool, the first could be called :initial, then either :pickaxis or :dragaxis depending upon how the user uses the mouse, then :pickpoint1 and then :pickpoint2, (or :pickangle,) etc.

Another thing I wonder. How would we see when tools are switched to “copymode” or “alignmode”, ie, modifier modes with SHFT, CTRL, ALT keys (or combinations.)

3 Likes
3

You have my vote. This would be wonderful.

Still, Any workaround in mind for the short term?

4

I gave a bit of thought to this one and I really like your solution. I think we would need to go one step further. The perfect scheme would be to split action and tools. Many tools can be used to do more than one action : the Move tool can be used to turn object, etc.

The steps would be :

  • activate a tool (ex: Move)
  • start an action (ex: Rotate, by clicking on the red cross on the selected object)
  • emit event for action steps/state (ex: Pick point & angle, drag angle, etc)
  • emit event for action end / cancel

just my $0.02

5

It also occurs to me it might be beneficial to have some new callbacks for communicating picked points and vectors to ToolsObserver objects.
Such as:

#onToolPointPicked(tools, tool_name, tool_id, tool_step, point, transform)

#onToolVectorDrawn(tools, tool_name, tool_id, tool_step, vec, transform)

#onToolAngleGiven(tools, tool_name, tool_id, tool_step, ang)

#onToolLengthGiven(tools, tool_name, tool_id, tool_step, len)

#onToolExtraInfo(tools, tool_name, tool_id, tool_step, infoname, infoclass, info)

1 Like