[Development] QPushButton: drag and drop

[Laszlo Papp]

On Tue, Jun 7, 2022 at 8:26 PM Giuseppe D'Angelo <giuseppe.dangelo at kdab.com>
wrote:

> Il 07/06/22 20:57, Laszlo Papp ha scritto:
> > Just checked the Qt wiki, but it does not seem to speak about this rule.
> > Only binary and source compatibility. No behaviour compatibility. And by
> > the way, fixing the bug to match the documentation and therefore
> > intended behaviour would not even be behaviour break.
> >
> > https://wiki.qt.io/Qt-Version-Compatibility
> > <https://wiki.qt.io/Qt-Version-Compatibility>
>
> There's behaviour break and behaviour break.
>
> Here we're talking about a fundamental change to how Qt has (not?)
> handled mouse release notifications on DND. I can wager there's also
> other many other similar situations (e.g. while having the mouse grab, a
> widget gets hidden, or a modal window opens up, etc.) that are currently
> similarly unhandled. Bonus points for "user cancels DND with the
> keyboard (escape) and releases into the widget", "a modal window opens
> up and closes down while the user never releases the mouse", etc.
>
>
> I'm calling it a "fundamental" change, because
>
> * any widget currently handling DND already does not expect to receive
> any event when DND is done; this may cause a further bug, for instance a
> widget gets a mouse release when it thinks it never saw the
> corresponding press;
>
> * any widget currently NOT handling DND (e.g. QPushButton) needs to
> handle the fake release event, in whatever way it's delivered.
>
> which is a long way to say "any QWidget subclass handling mouse events
> needs to be changed". And that's a very high bar for a behavioral change.
>
>
> If anything, this could start on a opt-in basis (a widget attribute set
> by the user, possibly also an application attribute, if you're feeling
> adventurous) and slowly starting fixing any misbehaving widget in the
> span of 2-3 minor releases, then we flip the attribute for next LTS (opt
> out instead of in), then it's the default in Qt 7.
>

I am not asking for a fake release event myself, just the usual one. If
someone manages the state restore manually, that would not be broken by the
usual release happening as far as I can see.

I was thinking of drag and drop setting an internal state for the QWidget
which then the QWidget can use to decide whether to emit clicked() or not
to address Volker's concern?

In worst case, if this idea is not viable, then sure, I still think it is
better to go for opt-in than what we have today (or have had for 12 years
at least). We have to start somewhere, yes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20220608/77a57e54/attachment-0001.htm>