[Qt-interest] QgraphicsScene: best way to manage events

Oliver.Knoll at comit.ch Oliver.Knoll at comit.ch
Fri Nov 26 11:36:31 CET 2010


On 2010-11-25 Christian Christian Gagneraud wrote:

> ...
> So, for what I understood, I would have to implement the
> ToolInterface::event() function which will have in turn to call the corresponding
> virtual event handlers (ToolInterface::mouseMoveEvent(),
> ...) depending on the event::type().

I am not sure, but I think you don't even have to re-implement any "filter" function, nor to expose such an event() method in your tool interface.

The only requirement is that your tools inherit from QObject, so that they can be sent a QEvent (the easiest way would be to inherit your tool interface from QObject, with the drawback that it would technically not be a "pure" interface anymore).Otherwise do a dynamic_cast<QObject *> on the ToolInterface in your code.

So I guess the following should work:

// interface does not need to expose any mouse/keyboard handler methods
class ToolInterface : public QObject {
  Q_OBJECT
public:
  virtual QString getDescription() const = 0;
  virtual void doFoo() = 0;
signals:
  // as a nice side-effect from having your tool interface inherit from QObject is that you can
  // already specify signals, and the concrete tools can easily emit them.
  // Like this the signals are also already part of the "tool contract" and
  // you can easily connect() to them without casting your ToolInterface to QObject etc.
  void fooHappened();
  ...
};

void MyGraphicsScene::mousePressEvent (QGraphicsSceneMouseEvent *event) {
  ...
  ToolInterface *activeTool = getActiveTool();
  bool processed = QCoreApplication::instance()->sendEvent(activeTool, event);
  // if the event was not handled by the active tool, let the base class deal with it!
  if (!processed) {
   QGraphicsScene::mousePressEvent(event);
  }
}

And that's it! The concrete tools then simply need to re-implement the usual mousePressEvent() etc. methods they are interested in, but these methods don't need to be exposed in the ToolInterface, nor does the tool require to re-implement http://doc.trolltech.com/4.7/qobject.html#event - the standard implementation should already take care of calling the proper method (mousePressEvent() etc.) - to be verified in pracise ;)
 

Note that http://doc.trolltech.com/4.7/qobject.html#event returns true if the event was processed. I strongly guess this is the case when http://doc.trolltech.com/4.7/qevent.html#accept was called.

Refer again to http://doc.trolltech.com/4.7/qcoreapplication.html#notify which lists all possible methods, 1 to 5, how to deal with QEvents. Unless you want to explicitly deal with some special keys such as Tab (which might change the focus widget) doing method 1 (re-implement mousePressEvent() etc.) should be enough in most cases.

Cheers, Oliver
--
Oliver Knoll
Dipl. Informatik-Ing. ETH
COMIT AG - ++41 79 520 95 22






More information about the Qt-interest-old mailing list