User Tools

Site Tools



Mixxx 1.11 doesn't work very well on touchscreen desktop devices. This was reported in some bugs like

These bug reports contain many details and further links, but are cluttered due to the post style. So here is a brief overview:

OS level touch to mouse solution

All three desktop OSs have a native mouse emulator for touchscreens for using legacy applications which do not handle touch events directly. Usually right clicks are generated by some kind of gesture or key combination. It is only a single pointing device emulated to achieve maximum compatibility.

Unfortunately these solutions are optimized for widgets that take effect on release. Since Mixxx widgets can be configured to emit on down-press, these solutions are not immediately usable. We do not have time to detect a right click gesture without delaying the left click.

Here is an overview of the different native right click solutions:

Windows 8

  • Right click = Release after long push


  • Right click = long push
  • Right click = Two finger click


  • Right click = two finger tap
  • Right click = control button + click

Mixxx Right click solution

  • Two finger tap → will issue the left click as well because you can't tap simultaneously
  • Drag out → will issue the left click as well
  • Hold (Long press) → will issue the left click as well
  • Context Menu button Or Shift+F10 → you cannot focus a button without left click
  • Ctrl+Click/Tap → works :-)

A solution for the right click problem is to introduce a shift button – similar to how OS X emulates right clicks. introduces a “[Controls]”, “touch_shift” Control Object which can be connected to a GUI button, a keyboard key or a controller button. Once this is >0, all touch taps will be interpreted as right clicks.

This allows us to issue right and left clicks without additional latency to detect a gesture.

Please note: We have already discussed a way to generalize the shift key in Mixxx. We might remove “[Controls]”, “touch_shift” once this is introduced.

Multi touch

All legacy widgets only support one pointing device. A second point might produce failure. Consequently the native touch to mouse solutions only support single touch. Once it is active the application does not receive any touch events. This works for all legacy applications, but we lose the benefit of multi touch.

The Qt4 solution relies on that. This means, if you enable touch for a single widget, the native touch to mouse solution is disabled. This way we have nice multi touch support on Mixxx's buttons but no touch at all for the library.

In Qt5 this problem is solved by Qt's own touch to mouse solution which is configurable per widget.

To fix this for Qt4 the Qt5 solution was introduced by overwriting Qt4 functions. See In this fallback solution only supports a single pointing device to be compatible with all legacy widgets.

Normally, widgets will lose their pressed state when losing the focus. This is normal if we have a single pointing device. The widget implementation expects it and may rely on it.

If we need to control multiple widgets at the same time the pressed state should not be tied to focus. In this case we have no mouse emulation, but real multi touch support. This was implemented on the widget itself.

So you will find both solutions in 1.) A single point touch mouse emulation for all widgets in MixxxApplication. The touch point behaves exactly like a mouse. 2.) A real multi touch solution in WWidget. It is still using mouse events, but the widgets are prepared. This solution is not affected by the focus.

Translations of this page:
touch.txt · Last modified: 2014/02/19 17:22 by rryan