It's possible to reproduce many engine-provided behaviors in a custom scripted implementation. We can also write our own amortization functions, craft our own HTTP handlers using sockets directly, and even create buttons from images if we like.
And I've done all of those. But rarely.
In each case I've asked myself what is the compelling benefit of taking on the expense of rolling my own rather than just using what's provided in the box for the purpose.
It varies from app to app. Most of the time I generally avoid reinventing provided wheels. But there are times when I've had to increase costs by choosing to craft a custom implementation because of some nuance not provided in the engine-based solution. I weigh such decisions very carefully, having been in this biz long enough to know the protracted cost of technical debt.
In this discussion of emulating built-in tool modes that have been a foundational part of xTalks since HC 1.0, it may be worth reviewing one of the more complete implementations I've ever seen in our community, Ken Ray's Stykz:
https://www.stykz.net
I was in touch with Ken throughout much of that development process, and can answer many questions about how he pulled it off, and why. And for anything I can't answer I can see if he can spare a moment to drop in here if needed.
For the WHY of his pointer tool implementation, at the heart of that decision was inverse kinematics. Stykz makes stick figure animations, and doing so efficiently requires the underlying code to maintain relationships between the parts of a figure (forearm connected to upper arm, shoulder to torso, etc.). When moving a selected part of a figure, app-specific intelligence is needed to maintain the figure's functional integrity.
Obviously that's far beyond what the humble Pointer tool does, since the built-in tool mode was designed to provide only behaviors of the sort we commonly see in drawing apps like MacDraw, Illustrator, Inkscape, etc.
So given the highly specialized needs of his app, Ken bit the bullet hard, and crafted one of the finest Pointer tool emulations I've ever seen.
For the HOW of it, he maintains multiple groups for each control. Some include the parts of the stick figure itself, grouped in ways that make the logic of linking their kinematics manageable.
Another set of groups is used to maintain the selection handles, one set of handles per object, where each handle is a graphic object. These are within a master group both to show/hide them easily, but mostly to keep the handles on top in the layer order, so that no figure element obscures use of a handle.
The selection marquee is done as you'd expect, a rectangle graphic object shown when the mouse is down outside of any control and moved beyond a reasonable slop rect to distinguish drags from clicks. When the mouse is eventually released, the code compares the rect of the marquee graphic to every user-made object to determine intersection, and then shows the selection handle group for that object (or set of objects, since many things users interact with in Stykz as a single object are implementated under the hood as a collection of objects in a group).
There are other details, but this at least provides an overview of the sort of things we will encounter when we choose to reproduce engine-provided behavior in bespoke script.
Given the level of effort needed to meet user expectations for something as common as a Pointer tool mode, maybe the most valuable part of this outline is the depth he explored first before attempting this. Only when all engine-provided solutions were identified as insufficient for the needs of this specific app did he decide to undertake the considerable effort to reproduce in script what the engine team worked so hard for so long to provide for us.
Ken and I sometimes joke about making t-shirts that read:
Know the engine.
Trust the engine.
Use the engine.