constness

[KAlO2]

Hi @robertosfield, thanks for this great library, and happy new year!

I have a small question regarding intersection operations with vsg::LineSegmentIntersector. The example vsgExamples/vsgintersection simply prints node information without modifying any node data.

for (auto& node : intersection->nodePath)
{
	std::cout << ", " << node->className();
	if (node->getValue("name", name))
		std::cout << ":name=" << name;
}

Highighting the closest intersected object (e.g., changing its base color, or visually expanding it) is currently implemented on my side. Since vsg::Intersector inherits from vsg::ConstVisitor, and surely we won't change node information during traversal. My question is: should VSG provide developers with non-const Node* or should developers resort to const_cast<Node*>(const_node) if they need to modify a node?

class Intersector : public Inherit<ConstVisitor, Intersector>
{
public:
	using NodePath = std::vector<const Node*>;
	
protected:
	NodePath _nodePath;
};

---

Another related, though less critical, issue concerns vsg::UIEvent. Event information is passed from the underlying operating system up to the application layer, and the data is essentially never modified, I initially implemented an EventHandler inheriting from ConstVisitor:

class EventHandler : public vsg::Inherit<vsg::ConstVisitor, EventHandler>
{
public:
	void apply(const vsg::KeyPressEvent& event) override;
	void apply(const vsg::PointerEvent& event) override;
};

However, I later discovered that vsg::Viewer only accepts vsg::Visitor, not vsg::ConstVisitor, so I abandoned this approach. This leads me to wonder: should event parameters be const even in vsg::Visitor?

using EventHandlers = std::list<vsg::ref_ptr<vsg::Visitor>>;

class Viewer : public Inherit<Object, Viewer>
{
public:
	void addEventHandler(ref_ptr<Visitor> eventHandler) { _eventHandlers.emplace_back(eventHandler); }
	
	EventHandlers& getEventHandlers() { return _eventHandlers; }
	
protected:
	EventHandlers _eventHandlers;
};

[robertosfield]

Event handlers can modify the events passed in, typically it'll be setting the UIEvent::handled flag so that event handlers later in the sequence know that the event is already handled so they don't get handled twice. One assigns the event handlers to viewer in the sequence you want them to take priority. The event handlers also are intended to be invoked single threaded as the viewer does.

As this is standard approach for handling events it makes sense to use Visitor is used rather than ConstVisitor as a base class. Often event handlers will also be modifying the scene graph in response to events.

In the case of Intersector classes, it's query of the scene graph rather than an operation on it, potentially one that could be done multi-threaded so this works more naturally as a const visitor. If you want to use the results of intersector and modify the objects then you'll need to cast away constness, when you do this you'll need to recognize the consequences of it, so if you do the interesections multi-threaded then any scene graph modifications will need to be scheduled in a thread safe way.