Sketchup::Axes#reset()

[DanRathbun]

SketchUp Ruby API Improvement

Symptom

If somehow the user or an extension changes the objects pointed at by the global constants ORIGIN, X_AXIS, Y_AXIS or Z_AXIS then this workaround fails ...

Sketchup::active_model.axes.set(ORIGIN,X_AXIS,Y_AXIS,Z_AXIS)

Feature Request

Please implement a low-level reset method from the C-side that will reset the drawing axes to the model's base axes so we don't have to employ weird workarounds like ...

class Sketchup::Axes

  # Resets the current drawing axes to the model's base axes.
  #
  # @return [Sketchup::Axes] The singleton axes object itself.
  #
  def reset(*)
    set(
      *Geom::Transformation::new.instance_eval {
        [ origin, xaxis, yaxis, zaxis ]
      }
    )
  end if !instance_methods(false).include?(:reset)

end

[thomthom]

If somehow the user or an extension changes the objects pointed at by the global constants I'm not sure I understand what you mean by this. Objects pointed to by global constants?

[DanRathbun]

@thomthom I'm not sure I understand what you mean by this. Objects pointed to by global constants?

Ruby has only 2 things. Objects and references that point at objects.

So called Ruby constants are mere references (aka identifiers) that point at objects of various kinds. But Ruby still allows these references to be reassigned to point at other objects rather than those they were first assigned to point at. It is getting harder with newer and newer Ruby version, however. At this time we get warnings when a constant is reassigned at the toplevel or in bare class or module code. The only thing that has been prevented (at Ruby v2.0) is dynamic constant re-assignment from within methods.

Sketchup is a constant reference that points at the main namespace module object for SketchUp's API. The SketchUp API also defines many other constant references, and among them are the toplevel constant references that we are concerned with here, and the type of object they reference :

• ORIGIN => Geom::Point3d
• X_AXIS => Geom::Vector3d
• Y_AXIS => Geom::Vector3d
• Z_AXIS => Geom::Vector3d

... which was clearly stated in my OP ...

If somehow the user or an extension changes the objects pointed at by the global constants ORIGIN, X_AXIS, Y_AXIS or Z_AXIS then this workaround fails ...

Sketchup::active_model.axes.set(ORIGIN,X_AXIS,Y_AXIS,Z_AXIS)

So if some newb (or their poorly written plugin) reassigns the global constant reference ORIGIN ...

ORIGIN = Geom::Point3d::new(10,10,10)
#=> <main>: warning: already initialized constant ORIGIN
#=> (10", 10", 10")

... then the user changes the drawing axes somewhere (and/or orientation) else ... then uses a macro (or menu command, etc.) that does this in an attempt to reset the axis ...

Sketchup::active_model.axes.set(ORIGIN,X_AXIS,Y_AXIS,Z_AXIS)

... the axis are not reset to the base model axes orientation.

---

Perhaps you do not remember that I brought up the lack of a #reset method in the cycle when the Sketchup::Axes class was first deployed (autumn of 2015,) and you agreed it was an oversight, but that we were past code-freeze then. That was 3 cycles ago! It's long past time to fix this omission.

[DanRathbun]

@thomthom Is this enough "more information" for ya' ? :wink:

I'd thought one of us had already filed a FR for this back in the SU2016 cycle ?

[thomthom]

Logged as SU-38571