When QGraphicsView is not flexible enough

April 5, 2010

Last week, when I added rubberband selection to Palapeli, I sacrificed the “Clicking with left mouse button moves viewport” option because it conflicts with the rubberband. Knowing that more mouse actions are yet to be added, I needed a scalable solution. I found inspiration in Plasma’s ContainmentActions:

The idea for Palapeli: Separate the triggers (mouse buttons or mouse wheel orientations, and keyboard modifiers) from the actions (e.g. move piece, zoom viewport, resize scene). This was essentially what I have implemented over the last two days. This is not visible because there is no nice configuration interface such as the one shown above yet, but you can already change the hard-coded triggers in src/engine/interactormanager.cpp.

The only problem with this new approach is that I have to bypass QGraphicsView’s mouse event handlers nearly completely.

Besides that, I have greatly improved the speed of puzzle loading, and the rendering performance for big puzzles. When pieces snap together, their pixmaps are combined into one, so only one pixmap needs to be drawn. Again, this change is not visible, though I hope you notice it. đŸ™‚

The only visible change is the new look of what is called “ConstraintVisualizer” internally: The size of the puzzle table can be changed by dragging its edges. In Palapeli 1.0, the only way to discover this feature is to notice that the mouse cursor changes into double-headed arrows near the puzzle table edges. The area where this interaction is possible is now visible as a transparent dark shade.

Advertisements

7 Responses to “When QGraphicsView is not flexible enough”


  1. I had something similar with KActions and QGraphicsMouseEvents*, bypassing the mouse events too, but I found quite easy to work with =)
    on the in the events, I simply did MousePressEvent( MouseEvent e){ _activeAction -> mousePress(); }

    worked like a charm. =)
    of course I had to implement an AbstractAction with mouses events for all my

    • Stefan Majewsky Says:

      It actually is that simple, though there are some caveats:
      1. I’m using QGV’s resizeAnchor and transformationAnchor methods, so I need to propagate all mouse move events to the QGV base class implementation. I’m sending rewritten events without any mouse buttons set.
      2. Without QGV event handling, no events are delivered to the items. This means I have to implement all mouse interaction for all items by myself.

  2. Parker Says:

    Hmm. Maybe I should be looking into something similar in Killbots. I allow assignment of actions to right and middle clicks, but currently I just use a couple of comboboxes. It’ll be interesting to see what you come up with for a UI.

  3. David Says:

    Did you think of double-click (double tap on touch-speak) and drag to do rubber band selection?

  4. Alexis Menard Says:

    It’s flexible enough because at the end you’ll manage to achieve what you wanted. Overriding events is the way to go and forward them to the base implementation if not needed.


  5. […] already spoiled this big change earlier this month: Any mouse interaction with the puzzle table can now be configured to arbitrary mouse buttons and […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s