QCustomPlot Discussion and Comments

Hi Emanuel,

In my application I put several QCustomPlots inside a QScrollArea (along with some text, buttons, etc.). I do not enable zoom interaction for QCustomPlots and expect that mouse wheel would scroll the contents of the scroll area. It does so, unless I place the mouse cursor on one of the plots. In this case mouse wheel does not work.

The reason behind this is that QCustomPlot (unlike standard Qt widgets) explicitly disables mouse event propagation to parent widget by calling setAttribute(Qt::WA_NoMousePropagation) in its constructor. If I manually re-enable event propagation then scrolling works as expected. Is there any specific reason that it is disabled by default?

Mikhail

Yes, the propagation is disabled because it caused problems on KDE. On KDE it was impossible to use mouse interactions at all when the propagation was enabled, instead, KDE just dragged the whole window the plot was in.
The problem is I can't know whether the user wants interactions or not (e.g. also the signal emissions, which are not dependent on setInteraction). So I guess manually re-enabling the mousepropagation is the way to go. I currently don't see a way for QCustomPlot to automatically figure out itself whether it shall enable or disable mouse propagation at a given moment.

Thanks for the information.

Dear all,

I want to add come comment to this old thread. I just checked that setAttribute(Qt::WA_NoMousePropagation, false) for a QCustopmPlot instance doesn't break any interactions on KDE Plasma (plasmashell 5.24.5; Qt 5.15.3; KDE Frameworks 5.93.0). So perhaps the original incompatibility bug has gone and there is no need to keep this attribute enabled in the QCP. If anyone else knows about the current situation in various desktop environments, it would be nice to hear about it.