Re: [Development] QPushButton: drag and drop

[Volker Hilsheimer]

> On 9 Jun 2022, at 17:54, Giuseppe D'Angelo  wrote:
> 
> Hi,
> 
> On 09/06/2022 17:20, Volker Hilsheimer wrote:
>> Let’s put things into a perspective here. You are proposing a flag that we 
>> perhaps flip on by default within Qt 6, and that might break a whole ton of 
>> widgets out there that today correctly implement drag’n’drop and that will 
>> start failing in mysterious, and largely untestable (because testing 
>> drag’n’drop requires special tools) ways. “Adventurous” indeed :P
>> We are having this discussion is because a widget doesn’t get a 
>> QEvent::MouseButtonRelease in symmetry with an earlier MouseButtonPress. As 
>> I pointed out earlier, a widget also won’t get a symmetrical 
>> MouseButtonRelease when a modal dialog opens in response to press; the 
>> release gets eaten by the dialog. (And we have bugs with enter/leave like 
>> the one Gatis pointed at, which in my mind are orthogonal to this, and is 
>> not addressed by any of the proposals made in this thread so far anyway; but 
>> those would be good bugs to fix in order to familiar with the complexity of 
>> the code involved here).
>> You are suggesting that all widgets in Qt, and possibly thousands of custom 
>> widget implementations out there, have to start adding special code to their 
>> mouseReleaseEvent, ignoring specially flagged events because someone might
>> * subclass that widget class and exec() a QDrag or a QDialog in 
>> mousePressEvent
>> * or connect to a pressed() signal (if that exists) and do the same
> 
> I think there's been a misunderstanding: I am 100% *agreeing* with you here. 
> Changing this behavior suddenly/blindly is a a big no-no, exactly for the 
> reasons you're stating.
> 
> Just like you here I was challenging the claim that "well it's a behavior 
> change but any fix is a change so let's fix this". This is what I said:
> 
>> There's behaviour break and behaviour break.
>> 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.
> 
> ^^^ In other words, I'm NOT for start sending mouse release events around.
> 
> Trying to be constructive: the most conservative approach would probably be a 
> custom event. Not a mouse release with a special source, another event 
> altogether, so that existing widgets do not handle it at all, and cannot 
> possibly misbehave. (Then QPushButton & friends could be "fixed" by handling 
> this event instead.)
> 
> Sending a release instead/in addition to a custom event _might_ be added, but 
> only behind an opt-in fence (per-widget attribute), which has to be opt-in 
> for a very long time, which makes it unpalatable to me (niche use case; noone 
> will enable it => lack of testing; already covered by the custom event 
> anyways).
> 
> 
>> And since the argument is “we must be symmetrical with our events so widgets 
>> don’t remain in a pressed state”, we cannot really fix the one (QDrag) and 
>> not the other (QDialog). If a widget author cannot be expected to maintain 
>> their widget state before or after calling QDrag::exec in a mousePressEvent 
>> handler, then they cannot be expected to manage their widget state before or 
>> after calling QDialog::exec, either.
>> So, if we deliver the release at the end (or beginning?) of the QDrag, then 
>> we have to deliver the release when a modal dialog opens (or closes?), 
>> because these are the exact same things (user interface enters a different 
>> mode, so events get eaten and handled by that mode, which results in 
>> asymmetry). And I am not at all convinced that we should send a 
>> QEvent::MouseButtonRelease to a widget that opens a modal dialog in their 
>> mousePressEvent handler. I’d consider that a bug, breaking the meaning of 
>> “modal”. And a drag’n’drop, as it stands today, is modal (no dialog and 
>> window activation state as the visual cue, but instead the mouse cursor 
>> shows that you are dragging something; your desktop will behave differently, 
>> maybe give you other visual cues).
> 
> Indeed modal dialog and modal DND are the same thing here. They could both 
> deliver a special event ("mouse grab lost event" or whatever).
> 
> (Here's a twist: is the grab truly lost? What if the modal dialog/DND closes, 
> and you never released the mouse? Do you still get mouse events or not? If 
> yes, do we also need a "mouse grab re-acquired" event? :-))
> 
> 
>> Perhaps you don’t agree that QDrag::exec starts a modal user interface state 
>> similar to a modal dialog? Then the next question is whether we need to deal 
>> with key events during the drag. Should we send shift/alt/control key 
>> presses to the widget as well? Today those are entirely handled by the 
>> drag’n’drop machinery to switch the drag operation. How about wheeling the 
>> mouse during a drag? Either we are modal (events get eaten) or we are not 
>> (events get processed by the grabbing or focus widget). Today we are modal. 
>> Changing 

Re: [Development] QPushButton: drag and drop

[Giuseppe D'Angelo via Development]

On 10/06/2022 06:48, Laszlo Papp wrote:
I do not know what you mean. From what I can see, it is not going to 
break anything. Those customers who worked around the design flaw, in my 
opinion (you are free to disagree of course), they will not notice the 
fix because they have not started handling the release event themselves. 
So, how could something break that they have not used?


Take for instance QAbstractItemView. You drag something from it, right 
now it does not receive a release. But say it starts receiving a 
release, it may start editing the current item because has an edit 
trigger to start editing on single click or something like that.


Pushbuttons or toolbuttons may start triggering clicked(), and so on.

In short, there are concrete possibilities of a breakage here if you 
merely send a _release_.


Now I'm not saying that a release makes NO sense. It does, but it's one 
of those scenarios "if we had a time machine and did it 20 years ago". 
Right now I'm really afraid that such a change will do more harm than 
good (although I don't have numbers, i.e. I didn't implement the change 
and checked for breakages.)


My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts


smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QPushButton: drag and drop

[Laszlo Papp]

> You are proposing a flag that we perhaps flip on by default within Qt 6,
> and that might break a whole ton of widgets out there that today correctly
> implement drag’n’drop and that will start failing in mysterious, and
> largely untestable (because testing drag’n’drop requires special tools)
> ways.
>

I do not know what you mean. From what I can see, it is not going to break
anything. Those customers who worked around the design flaw, in my opinion
(you are free to disagree of course), they will not notice the fix because
they have not started handling the release event themselves. So, how could
something break that they have not used?

Moreover, if someone really went the nasty way of manually managing the
internal state machine of each and every QWidget subclass instances and
updating that on every Qt update where potentially changes, what my
proposed fix would mean for that the state would not be potentially
restored manually and internally. Which is fine, it is an extra no-op, but
it would not actually break anything.

So, I am a little surprised by seeing claims about "tons of breaks"
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QPushButton: drag and drop

[Laszlo Papp]

On Thu, Jun 9, 2022 at 4:20 PM Volker Hilsheimer 
wrote:

> > 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.
>
> You are asking for a release event to be delivered to a widget, even
> though the release event was already handled (and eaten) by the modal
> state. That’s a fake/synthesized event in my book. And if we deliver such
> an event, then we have to deliver the event to any widget that starts a
> drag. And since by overriding mousePressEvent, any widget can start a drag,
> all widgets have to handle that new release event, if only by ignoring it
> if the source is some new SynthesizedByQtForReasons flag.
>

I have an opposing view to this. In my opinion, the release event would be
native, natural and intuitive here. In my opinion, what is fake is what
QDrag is currently here. It does something unnatural and unintuitive.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QPushButton: drag and drop

[Laszlo Papp]

On Thu, Jun 9, 2022 at 4:20 PM Volker Hilsheimer 
wrote:

> > 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?
>
> Which in the case of QAbstractButton means a change to the
> mouseReleaseEvent implementation, testing for that flag being set, and the
> event’s source flag being set, and then maybe not emitting clicked().
>
> So just because you are adding drag support to your QPushButton subclass
> and don’t want to maintain the button’s state yourself if a drag is started
> (or finished), the author of QAbstractButton now needs to somehow deal with
> this.
>

Not necessarily the original author, just the person writing this
particular patch. It is a collaborative effort. But yes, I am proposing
that one codepath deals with it rather than many. Sounds like the right
decision for me in software development though.

Please do not forget that the initial manifestation was QPushButton, but
the issue has actually nothing to do with QPushButton in particular. It is
a generic QWidget issue of not releasing the widget. You will probably
agree that when you stop the drag-and-drop, you release the mouse. This is
the intuitive behaviour, so as a user, or the user of the API, you would
not expect that the widget gets stuck. So, this is the use case the API
should cover. In my opinion, it was not correctly designed, which is fine.
Mistakes happen. But going forward, we need to improve this.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QPushButton: drag and drop

[Giuseppe D'Angelo via Development]

Hi,

On 09/06/2022 17:20, Volker Hilsheimer wrote:

Let’s put things into a perspective here. You are proposing a flag that we 
perhaps flip on by default within Qt 6, and that might break a whole ton of 
widgets out there that today correctly implement drag’n’drop and that will 
start failing in mysterious, and largely untestable (because testing 
drag’n’drop requires special tools) ways. “Adventurous” indeed :P

We are having this discussion is because a widget doesn’t get a 
QEvent::MouseButtonRelease in symmetry with an earlier MouseButtonPress. As I 
pointed out earlier, a widget also won’t get a symmetrical MouseButtonRelease 
when a modal dialog opens in response to press; the release gets eaten by the 
dialog. (And we have bugs with enter/leave like the one Gatis pointed at, which 
in my mind are orthogonal to this, and is not addressed by any of the proposals 
made in this thread so far anyway; but those would be good bugs to fix in order 
to familiar with the complexity of the code involved here).

You are suggesting that all widgets in Qt, and possibly thousands of custom 
widget implementations out there, have to start adding special code to their 
mouseReleaseEvent, ignoring specially flagged events because someone might

* subclass that widget class and exec() a QDrag or a QDialog in mousePressEvent
* or connect to a pressed() signal (if that exists) and do the same



I think there's been a misunderstanding: I am 100% *agreeing* with you 
here. Changing this behavior suddenly/blindly is a a big no-no, exactly 
for the reasons you're stating.


Just like you here I was challenging the claim that "well it's a 
behavior change but any fix is a change so let's fix this". This is what 
I said:



There's behaviour break and behaviour break.

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.


^^^ In other words, I'm NOT for start sending mouse release events around.

Trying to be constructive: the most conservative approach would probably 
be a custom event. Not a mouse release with a special source, another 
event altogether, so that existing widgets do not handle it at all, and 
cannot possibly misbehave. (Then QPushButton & friends could be "fixed" 
by handling this event instead.)


Sending a release instead/in addition to a custom event _might_ be 
added, but only behind an opt-in fence (per-widget attribute), which has 
to be opt-in for a very long time, which makes it unpalatable to me 
(niche use case; noone will enable it => lack of testing; already 
covered by the custom event anyways).




And since the argument is “we must be symmetrical with our events so widgets 
don’t remain in a pressed state”, we cannot really fix the one (QDrag) and not 
the other (QDialog). If a widget author cannot be expected to maintain their 
widget state before or after calling QDrag::exec in a mousePressEvent handler, 
then they cannot be expected to manage their widget state before or after 
calling QDialog::exec, either.

So, if we deliver the release at the end (or beginning?) of the QDrag, then we 
have to deliver the release when a modal dialog opens (or closes?), because 
these are the exact same things (user interface enters a different mode, so 
events get eaten and handled by that mode, which results in asymmetry). And I 
am not at all convinced that we should send a QEvent::MouseButtonRelease to a 
widget that opens a modal dialog in their mousePressEvent handler. I’d consider 
that a bug, breaking the meaning of “modal”. And a drag’n’drop, as it stands 
today, is modal (no dialog and window activation state as the visual cue, but 
instead the mouse cursor shows that you are dragging something; your desktop 
will behave differently, maybe give you other visual cues).


Indeed modal dialog and modal DND are the same thing here. They could 
both deliver a special event ("mouse grab lost event" or whatever).


(Here's a twist: is the grab truly lost? What if the modal dialog/DND 
closes, and you never released the mouse? Do you still get mouse events 
or not? If yes, do we also need a "mouse grab re-acquired" event? :-))




Perhaps you don’t agree that QDrag::exec starts a modal user interface state 
similar to a modal dialog? Then the next question is whether we need to deal 
with key events during the drag. Should we send shift/alt/control key presses 
to the widget as well? Today those are entirely handled by the drag’n’drop 
machinery to switch the drag operation. How about wheeling the mouse during a 
drag? Either we are modal (events get eaten) or we are not (events get 
processed by the grabbing or focus widget). Today we are modal. Changing that 
is a huge change, and IMHO a wrong change, also deviating from how every 
desktop environment seems to think about “drag and drop”.


But I also agree that DND is modal, where did I say otherwise?

I just don't like the _current QDrag API_ 

Re: [Development] QPushButton: drag and drop

[Volker Hilsheimer]

>> On 8 Jun 2022, at 19:52, Laszlo Papp  wrote:
>> 
>> 
>> 
>> On Tue, Jun 7, 2022 at 8:26 PM Giuseppe D'Angelo  
>> 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 
>> > 
>> 
>> 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.
>> 


Let’s put things into a perspective here. You are proposing a flag that we 
perhaps flip on by default within Qt 6, and that might break a whole ton of 
widgets out there that today correctly implement drag’n’drop and that will 
start failing in mysterious, and largely untestable (because testing 
drag’n’drop requires special tools) ways. “Adventurous” indeed :P

We are having this discussion is because a widget doesn’t get a 
QEvent::MouseButtonRelease in symmetry with an earlier MouseButtonPress. As I 
pointed out earlier, a widget also won’t get a symmetrical MouseButtonRelease 
when a modal dialog opens in response to press; the release gets eaten by the 
dialog. (And we have bugs with enter/leave like the one Gatis pointed at, which 
in my mind are orthogonal to this, and is not addressed by any of the proposals 
made in this thread so far anyway; but those would be good bugs to fix in order 
to familiar with the complexity of the code involved here).

You are suggesting that all widgets in Qt, and possibly thousands of custom 
widget implementations out there, have to start adding special code to their 
mouseReleaseEvent, ignoring specially flagged events because someone might 

* subclass that widget class and exec() a QDrag or a QDialog in mousePressEvent
* or connect to a pressed() signal (if that exists) and do the same

And since the argument is “we must be symmetrical with our events so widgets 
don’t remain in a pressed state”, we cannot really fix the one (QDrag) and not 
the other (QDialog). If a widget author cannot be expected to maintain their 
widget state before or after calling QDrag::exec in a mousePressEvent handler, 
then they cannot be expected to manage their widget state before or after 
calling QDialog::exec, either.

So, if we deliver the release at the end (or beginning?) of the QDrag, then we 
have to deliver the release when a modal dialog opens (or closes?), because 
these are the exact same things (user interface enters a different mode, so 
events get eaten and handled by that mode, which results in asymmetry). And I 
am not at all convinced that we should send a QEvent::MouseButtonRelease to a 
widget that opens a modal dialog in their mousePressEvent handler. I’d consider 
that a bug, breaking the meaning of “modal”. And a drag’n’drop, as it stands 
today, is modal (no dialog and window activation state as the visual cue, but 
instead the mouse cursor shows that you are dragging something; your desktop 
will behave differently, maybe give you other visual cues).

Perhaps you don’t agree that QDrag::exec starts a modal user interface state 
similar to a modal dialog? Then the next question is whether we need to deal 
with key events during the drag. Should we send shift/alt/control key presses 
to the widget as well? Today those are entirely handled by the drag’n’drop 
machinery to switch the drag operation. 

Re: [Development] QPushButton: drag and drop

[Laszlo Papp]

On Tue, Jun 7, 2022 at 8:26 PM Giuseppe D'Angelo 
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
> > 
>
> 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.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QPushButton: drag and drop

[Giuseppe D'Angelo via Development]

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 



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.



My 2 c,

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts


smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QPushButton: drag and drop

[Laszlo Papp]

On Tue, Jun 7, 2022 at 3:26 PM David Skoland  wrote:

> “If it’s a bug people rely on, it’s a feature”
>

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
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QPushButton: drag and drop

[Laszlo Papp]

On Tue, Jun 7, 2022 at 3:26 PM David Skoland  wrote:

> Hi,
>
> It is their problem if they have started relying on a bug.
>
>
> I don’t think this is a good way to approach this. When programming with a
> framework, you program based on the current behavior of that framework,
> regardless of what the “correct” behavior is supposed to be. I think it's
> pertinent to pull an insightful quote from Linus Torvalds here:
>
> “If it’s a bug people rely on, it’s a feature”
>

If your intention is to strengthen the argument for the bug with a famous
(or infamous, depending on one's point of view) personality, like Linus, or
anyone else, then I can say that it does not work for me. Just like it does
not work for the Darwin followers that Darwin rejected his idea on his
deathbed. That is because they are convinced by the idea objectively rather
than a personality, whose judgement can be subjective.


> Don’t get me wrong, this is definitely a useful discussion (thanks for
> bringing it up), but as I see it in light of Qt’s compatibility promises,
> drastically changing drag and drop behavior looks like a Qt7 point that
> should be further discussed. I personally think Shawn’s proposal seems very
> sensible at a glance.
>
> If I recall correctly, there was a list of major behavior changes for Qt6.
> If we decide to change this behavior, this point should probably be added
> to the Qt7 equivalent if one exists, in addition to an eventual porting
> guide.
>

Yes, I also suggested something similar on Discord to Volker, as far as I
can tell, that Shawn / Giuseppe before coming here for a discussion. It
does not look that it would warrant Qt 7 though. What makes you think so?

I personally think that not emitting the clicked signal, which was the
original concern, but releasing the widget would satisfy everyone here in
this discussion.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QPushButton: drag and drop

[David Skoland]

Hi,

It is their problem if they have started relying on a bug.

I don’t think this is a good way to approach this. When programming with a 
framework, you program based on the current behavior of that framework, 
regardless of what the “correct” behavior is supposed to be. I think it's 
pertinent to pull an insightful quote from Linus Torvalds here:

“If it’s a bug people rely on, it’s a feature”

Don’t get me wrong, this is definitely a useful discussion (thanks for bringing 
it up), but as I see it in light of Qt’s compatibility promises, drastically 
changing drag and drop behavior looks like a Qt7 point that should be further 
discussed. I personally think Shawn’s proposal seems very sensible at a glance.

If I recall correctly, there was a list of major behavior changes for Qt6. If 
we decide to change this behavior, this point should probably be added to the 
Qt7 equivalent if one exists, in addition to an eventual porting guide.

Cheers,
David Skoland

On 7 Jun 2022, at 08:47, Laszlo Papp mailto:lp...@kde.org>> 
wrote:

On Fri, Jun 3, 2022 at 11:08 PM Giuseppe D'Angelo via Development 
mailto:development@qt-project.org>> wrote:
Given the blame on that code shows no changes since Nokia times,
something just tells me that this has never worked properly and people
started 1) relying on the release to be never received

It is their problem if they have started relying on a bug. We cannot leave bugs 
around and stop fixing bugs because bugs have been released.

Moreover, not only has this not been documented to rely on, but in fact, even 
the opposite has been claimed by the Qt docs, so people really should not rely 
on the opposite of the design and documentation: 
https://doc-snapshots.qt.io/qt6-dev/qdrag.html#exec

"Other events are still delivered to the application while the operation is 
performed."

So, I feel like it is just to just fix the code as the documentation claims the 
behaviour.

So, yes, I agree with you that this is not something we should leave as is.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QPushButton: drag and drop

[Laszlo Papp]

On Fri, Jun 3, 2022 at 11:08 PM Giuseppe D'Angelo via Development <
development@qt-project.org> wrote:

> Given the blame on that code shows no changes since Nokia times,
> something just tells me that this has never worked properly and people
> started 1) relying on the release to be never received


It is their problem if they have started relying on a bug. We cannot leave
bugs around and stop fixing bugs because bugs have been released.

Moreover, not only has this not been documented to rely on, but in fact,
even the opposite has been claimed by the Qt docs, so people really should
not rely on the opposite of the design and documentation:
https://doc-snapshots.qt.io/qt6-dev/qdrag.html#exec

"Other events are still delivered to the application while the operation is
performed."

So, I feel like it is just to just fix the code as the documentation claims
the behaviour.

So, yes, I agree with you that this is not something we should leave as is.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QPushButton: drag and drop

[Laszlo Papp]

On Sat, Jun 4, 2022 at 9:41 AM Volker Hilsheimer 
wrote:

> I am fairly confident that this has been like this since the Qt 1.x days,
> and that it was designed to be like that. One can argue that we should have
> done things differently back then, but here we are.
>

I am sorry, but this sort of argument is limiting innovation. "We have
always done things like this, so even if incorrect now, we cannot change
it".

I am afraid that I cannot agree on this in general without going into the
specifics of this issue. We must be open to new point of views and ways of
thinking. Personally, I think that Shawn / Giuseppe's proposal are getting
in the right direction.

It feels wrong to suggest that Qt has an architecture where drag and drop
means widgets are never released. It does concern a few of us, apparently.

For sure, mouse press (-> drag and drop) -> release is the workflow a user
and therefore the developer for the user (your API user) would intuitively
expect. You may say that this can only be Qt 7 material and need a
workaround for Qt 6, which is fine for me. But let us improve things!
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QPushButton: drag and drop

[Laszlo Papp]

On Sat, Jun 4, 2022 at 6:26 AM Philippe  wrote:

> *I have also noticed several posts on Stack Overflow, Qt Centre, etc,
> about this issue without a "real solution". *
>
> I confirm. This case is very similar to user reports I've had for about 10
> years, on OSX only, that occur randomly. I've wasted countless hours on
> this with no solution. And without a good excuse to give to these users...
>
> Philippe
>

Hi Philippe,

I can reassure you that you are not alone. I have spent 1-2 days on this. I
do not think it is fair from Qt to expect each and every drag and drop
customers to manage each and every QWidget states manually. I have found
several users mentioning this across Stack Overflow, Qt Centre, Qt Forum,
etc. Just mentioned one instance, but this seems to have been a
long-standing issue for a decade or more. In my humble opinion, a fix
(whatever that may be) would be welcome. So, created a ticket for it now:
https://bugreports.qt.io/browse/QTBUG-104028
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QPushButton: drag and drop

[Laszlo Papp]

I will read the whole discussion later - do not have time for it now. But
just to confirm, I did not agree with Volker on discord that it is not a
bug.

I did think it was a bug. Volker raised the concern that if he cancels the
drag and drop, he would not expect a clicked signal to be sent. This is
fine. But the QWidget must be released even if clicked() is not emitted.

So, I do think that this ought to be fixed in Qt prior to reading the whole
thread.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QPushButton: drag and drop

[Volker Hilsheimer]

> On 4 Jun 2022, at 00:41, Giuseppe D'Angelo via Development 
>  wrote:
> 
> Il 04/06/22 00:39, Shawn Rutledge ha scritto:
>> This might resemble the case when a TouchCancel event is sent: it means the 
>> receiver should be un-pressed, undo whatever was done on press, and don’t 
>> react otherwise (e.g. a Button does not get clicked, it’s just not pressed 
>> anymore).
> 
> This is an interesting idea (either a new event or a flag on the release 
> event to know that "something else" has happened in the meanwhile, so it 
> shouldn't act as if it was a real release).


Yes, adding a new “cancel” event that informs a widget that it has lost the 
mouse grab could be an idea. We have QEvent::WindowBlocked/WindowUnblocked for 
instance to inform a window that it is about to get blocked/unblocked by a 
modal dialog.

I don’t think we deliver those events when the modal drag’n’drop starts (since 
it’s not a modal dialog blocking the window, which is the specific 
documentation of these event types). And since usually (at least when I refer 
to the widgets we have in Qt) the widget itself is responsible for starting the 
modal drag’n’drop, it knows exactly when the operation starts and ends. For 
that usage pattern, a new event adds no new information.

Adding a new event type allows us to dispatch drag-start/end information to the 
source widget (or all widgets? the entire window hierarchy?) without risking 
that we execute existing event handlers like mouseReleaseEvent. But then for 
Laszlo’s problem, he’d have to implement a new event handler just to call 
setDown(false), when he can do that right now already in the existing event 
handler form where he calls QDrag::exec.

Perhaps it’s useful in situations where an application calls QDrag::exec (or 
QDialog::exec) in response to a signal (such as QAbstractButton::pressed), 
instead of overriding event handlers. But then, would we expect that all 
widgets handle that event to cancel their interaction and reset their state 
(there is no sensible default implementation)? That would add a lot of state 
handling logic, to every widget class, for many of the signals they emit, just 
to support what seems to me like an extremely rare use case.

Volker

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QPushButton: drag and drop

[Volker Hilsheimer]

> On 4 Jun 2022, at 07:25, Philippe  wrote:
> 
> I have also noticed several posts on Stack Overflow, Qt Centre, etc, about 
> this issue without a "real solution".
>  
> I confirm. This case is very similar to user reports I've had for about 10 
> years, on OSX only, that occur randomly. I've wasted countless hours on this 
> with no solution. And without a good excuse to give to these users...
>  
> Philippe
>  

Hi Philippe,


We have fixed a whole bunch of macOS specific bugs with enter/leave/hover 
logic, and also with the handling of window modality on macOS; e.g.

https://bugreports.qt.io/browse/QTBUG-36926
https://bugreports.qt.io/browse/QTBUG-78970
https://bugreports.qt.io/browse/QTBUG-92040

Perhaps those are the issues you have been running into as well? There might be 
more, in which case it would be good to have specific bug reports.

Volker



> On Fri, 3 Jun 2022 13:20:31 +0100
> Laszlo Papp  wrote:
>  
> Hi,
> 
> It seems that QWidget::mouseReleaseEvent does not get triggered after 
> QDrag::exec. This causes the following issue that the QPushButton instance 
> gets stuck in "pressed down" (with pressed highlight, etc) state as the 
> following short gif shows: https://imgur.com/a/dk7zs9D
> 
> I worked this around by calling setDown(false); after drag->exec(...), but I 
> wonder if this is something that should be, or even can be fixed in Qt for 
> all OSes.
> 
> Here is a small testbed example I have put together that is really small and 
> reproduces the issue. This is what I also used for the above gif to show the 
> issue.
> 
> https://github.com/lpapp/examples/tree/main/qt-button-dnd
> 
> This is where the QDragManager::drag starts grabbing the mouse on Linux with 
> X11 for example: 
> https://github.com/openwebos/qt/blob/master/src/gui/kernel/qdnd_x11.cpp#L2026
> 
> I do not know the details very well, but from a user point of view, it would 
> be good to either let mouseReleaseEvent get triggered as usual after the 
> dragging has finished or at least not to have artifacts like the above around.
> 
> I have also noticed several posts on Stack Overflow, Qt Centre, etc, about 
> this issue without a "real solution". E.g. this dates back to 12 years ago: 
> https://www.qtcentre.org/threads/34539-Drag-and-drop-from-QPushButton
> 
> What do you think about this issue?
> 
> Thanks.
> 
> Kind regards,
> László
> 
>  
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QPushButton: drag and drop

[Volker Hilsheimer]

> On 4 Jun 2022, at 00:08, Giuseppe D'Angelo  wrote:
> 
> On 03/06/2022 23:05, Volker Hilsheimer wrote:
>> If we were to deliver a mouseReleaseEvent to the widget that initiated the 
>> drag via QDrag::exec after the exec returns, then we handle the 
>> mouseReleaseEvent twice.
> 
> Why twice? It receives only one?


The drag’n’drop system handles the mouse release event, and sends a drop-event 
to the drop target (which might be another process). Qt, in the general case, 
might never see a mouse release event (it doesn’t on Windows or macOS, for 
instance).


> Note that the infrastructure for sending a release when the drag ends is 
> already there:
> 
>> https://github.com/qt/qtbase/blob/dev/src/gui/kernel/qsimpledrag.cpp#L125


This is a special class for a special case - intra-application drag’n’drop. We 
can provide a simplified API like this for that specific case, but I don’t 
think we should start sending different events depending on the drop target.

On macOS for instance, the performDragOperation of our Dragging interface 
implementation gets called (in qnsview_dragging.mm) when you drop the drag. If 
the drop is performed within the Qt application that started the drag, then we 
can construct a QDropEvent from the information provided, and from the 
information we record in Qt during the preceding events (key modifiers and 
buttons etc). But if the drop is performed in another process, then we have no 
such information.

> It's just that in QtWidgets it never reaches the widget, as it gets filtered 
> out by QApplicationPrivate::pickMouseReceiver (called by 
> QWidgetWindow::handleMouse).
> 
> Given the blame on that code shows no changes since Nokia times, something 
> just tells me that this has never worked properly and people started 1) 
> relying on the release to be never received, and/or 2) add workarounds for 
> that.
> 
> 
> This isn't the only case where Qt event handling is very very inconsistent. 
> Leave/Enter events are also extremely unreliable (if a widget is shown under 
> the cursor, you may or may not get a enter event. Same for a widget moving on 
> its own, moving under or outside the cursor.)
> 

Indeed, we need to heavily rely on the windowing system for enter/leave 
dispatching to work when windows open. We spent a significant amount of time 
last year on fixing this on e.g. macOS, where we need to work around 
inconsistent OS behavior etc. It’s extremely difficult to test reliably in CI 
as well. I think we fixed all the cases, but if you still experience specific 
issues here, please open bug reports.

Anyway, off-topic-ish. Drag’n’drop is a special application mode - it’s modal, 
both in terms of interaction model, and in terms of programming model 
(QDrag::exec is a blocking call), and the fact that we hand control entirely 
over to the windowing system limits what we can do.


>> In the case of the button, it would mean that we emit clicked() if the drag 
>> is dropped inside the button. Check the following, which simulates that Qt 
>> would do that. Drag from the button, and drop the drag inside the button. 
>> The button now emits clicked(). You most certainly don’t want slot connected 
>> to that signal to execute in that interaction.
> 
> That's kind of an orthogonal story, that is, adding DND support on top of a 
> class that already uses mouse interactions isn't always possible. But you 
> could say the same for any other event-driven interaction when you start 
> messing with the received events. What if tomorrow we add DND support to 
> QPushButton itself, with the related logic in the mouse event handlers? Then 
> the overrides in the testcase will break (they might _re_start DND).


That is rather exactly my point, which I evidently failed to get across. 
Widgets that implement drag’n’drop handling today will update their states 
after QDrag::exec returns, usually while they are still in the mouseMoveEvent 
handler. Take for example QAbstractItemView and subclasses. Or they might do so 
before calling QDrag::exec (should the button stay pressed while you are 
dragging from it? only the widget author knows this). They have to do that 
anyway, because if the drag performed was a move-drag, then they need to remove 
their data.

If we now start delivering a mouse release event to the source widget when 
QDrag::exec returns, then we are executing mouseReleaseEvent code with the 
widget in a state in which it didn’t use to execute this code. Unknown things 
will happen. In my contrived example, we emit clicked() even though the users 
didn’t click the button (but instead dragged from it, then changed their mind). 
Should the mouseReleaseEvent handler be executed while we are still in 
QDrag::exec (resulting in reentrancy issues)? Or should we post an event and 
wait for the stack to unroll before running mouseReleaseEvent?

Widgets that implement drag’n’drop today don’t need a mouseReleaseEvent to know 
that the drag’n’drop operation ended: they know that 

Re: [Development] QPushButton: drag and drop

[Philippe]

I have also noticed several posts on Stack Overflow, Qt Centre, etc, about this 
issue without a "real solution". 

I confirm. This case is very similar to user reports I've had for about 10 
years, on OSX only, that occur randomly. I've wasted countless hours on this 
with no solution. And without a good excuse to give to these users...

Philippe

On Fri, 3 Jun 2022 13:20:31 +0100
Laszlo Papp  wrote:

Hi, 
> 
> 
> It seems that QWidget::mouseReleaseEvent does not get triggered after 
> QDrag::exec. This causes the following issue that the QPushButton instance 
> gets stuck in "pressed down" (with pressed highlight, etc) state as the 
> following short gif shows: https://imgur.com/a/dk7zs9D
> 
> 
> I worked this around by calling setDown(false); after drag->exec(...), but I 
> wonder if this is something that should be, or even can be fixed in Qt for 
> all OSes.
> 
> 
> Here is a small testbed example I have put together that is really small and 
> reproduces the issue. This is what I also used for the above gif to show the 
> issue.
> 
> 
> https://github.com/lpapp/examples/tree/main/qt-button-dnd
> 
> 
> 
> This is where the QDragManager::drag starts grabbing the mouse on Linux with 
> X11 for example: 
> https://github.com/openwebos/qt/blob/master/src/gui/kernel/qdnd_x11.cpp#L2026
> 
> 
> I do not know the details very well, but from a user point of view, it would 
> be good to either let mouseReleaseEvent get triggered as usual after the 
> dragging has finished or at least not to have artifacts like the above around.
> 
> 
> I have also noticed several posts on Stack Overflow, Qt Centre, etc, about 
> this issue without a "real solution". E.g. this dates back to 12 years ago: 
> https://www.qtcentre.org/threads/34539-Drag-and-drop-from-QPushButton
> 
> 
> What do you think about this issue?
> 
> 
> Thanks.
> 
> 
> Kind regards,
> László
> 
> 
> 

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QPushButton: drag and drop

[Giuseppe D'Angelo via Development]

Il 04/06/22 00:39, Shawn Rutledge ha scritto:

This might resemble the case when a TouchCancel event is sent: it means the 
receiver should be un-pressed, undo whatever was done on press, and don’t react 
otherwise (e.g. a Button does not get clicked, it’s just not pressed anymore).


This is an interesting idea (either a new event or a flag on the release 
event to know that "something else" has happened in the meanwhile, so it 
shouldn't act as if it was a real release).


My 2 c,

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts


smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QPushButton: drag and drop

[Shawn Rutledge]

> On 2022 Jun 3, at 23:05, Volker Hilsheimer  wrote:
> 
> This is of course a special case, but it shows that we can’t just start 
> delivering MouseButtonRelease events to widgets when a drag operation 
> finishes, because they would suddenly execute mouseReleaseEvent code in a 
> state in which they don’t expect it to.

This might resemble the case when a TouchCancel event is sent: it means the 
receiver should be un-pressed, undo whatever was done on press, and don’t react 
otherwise (e.g. a Button does not get clicked, it’s just not pressed anymore).  
And it’s inconsistent that we only have TouchCancel, but don’t follow this 
pattern for other device types.  Maybe we could rename it to PointerCancel 
(have both names point to one value in Qt 6, deprecate the enum name 
TouchCancel, and remove it in Qt 7).  Maybe QWindow::startSystemMove() should 
result in the platform plugin sending a PointerCancel event when it succeeds in 
taking over the mouse? Because that’s a case where Qt handles the mouse press, 
maybe some of the moves (up to the drag threshold), and then the platform takes 
over handling the rest of the moves and the release.

I didn’t dig too deep lately into DnD or startSystemMove() or the exact 
scenarios when TouchCancel events are sent, but there’s a half-baked idea 
anyway, that in all these cases the original grabber needs to be told that it 
will not be receiving any more updates.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QPushButton: drag and drop

[Giuseppe D'Angelo via Development]

On 03/06/2022 23:05, Volker Hilsheimer wrote:


If we were to deliver a mouseReleaseEvent to the widget that initiated the drag 
via QDrag::exec after the exec returns, then we handle the mouseReleaseEvent 
twice.


Why twice? It receives only one?

Note that the infrastructure for sending a release when the drag ends is 
already there:



https://github.com/qt/qtbase/blob/dev/src/gui/kernel/qsimpledrag.cpp#L125


It's just that in QtWidgets it never reaches the widget, as it gets 
filtered out by QApplicationPrivate::pickMouseReceiver (called by 
QWidgetWindow::handleMouse).


Given the blame on that code shows no changes since Nokia times, 
something just tells me that this has never worked properly and people 
started 1) relying on the release to be never received, and/or 2) add 
workarounds for that.



This isn't the only case where Qt event handling is very very 
inconsistent. Leave/Enter events are also extremely unreliable (if a 
widget is shown under the cursor, you may or may not get a enter event. 
Same for a widget moving on its own, moving under or outside the cursor.)





In the case of the button, it would mean that we emit clicked() if the drag is 
dropped inside the button. Check the following, which simulates that Qt would 
do that. Drag from the button, and drop the drag inside the button. The button 
now emits clicked(). You most certainly don’t want slot connected to that 
signal to execute in that interaction.


That's kind of an orthogonal story, that is, adding DND support on top 
of a class that already uses mouse interactions isn't always possible. 
But you could say the same for any other event-driven interaction when 
you start messing with the received events. What if tomorrow we add DND 
support to QPushButton itself, with the related logic in the mouse event 
handlers? Then the overrides in the testcase will break (they might 
_re_start DND).




This is of course a special case, but it shows that we can’t just start 
delivering MouseButtonRelease events to widgets when a drag operation finishes, 
because they would suddenly execute mouseReleaseEvent code in a state in which 
they don’t expect it to.


Yes, I'm not claiming that this should be a fix to cherry-pick back. 
Being likely a 10+ yo behavior, it's dev material only.




For instance, QAbstractItemView does not expect to get a mouseReleaseEvent when 
QAbstractItemView::startDrag returns. I didn’t test it, but it start the editor 
of the item that was dragged, which might crash when that index got removed by 
the drag!

Widgets that support drag’n’drop need to reset their state when QDrag::exec 
returns, and must be able to rely that they don’t get a mouseReleaseEvent when 
that mouse release already was processed by the drag’n’drop system to end the 
drag.


But this simply can't be done reliably in general, as you don't 
necessarily have access to that state so you can't reset it. Again, what 
if tomorrow QPushButton starts drawing itself differently depending on 
mouse movements, and wants to see the release to reset its drawing?



My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts


smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QPushButton: drag and drop

[Volker Hilsheimer]

> On 3 Jun 2022, at 18:07, Giuseppe D'Angelo via Development 
>  wrote:
> 
> On 03/06/2022 14:20, Laszlo Papp wrote:
>> I do not know the details very well, but from a user point of view, it would 
>> be good to either let mouseReleaseEvent get triggered as usual after the 
>> dragging has finished or at least not to have artifacts like the above 
>> around.
>> I have also noticed several posts on Stack Overflow, Qt Centre, etc, about 
>> this issue without a "real solution". E.g. this dates back to 12 years ago: 
>> https://www.qtcentre.org/threads/34539-Drag-and-drop-from-QPushButton 
>> 
>> What do you think about this issue?
> 
> That it's a bug. Did you search for submitted reports or did you submit one 
> yourself?

As discussed with Laszlo on discord, I don’t think it is a bug.

If we were to deliver a mouseReleaseEvent to the widget that initiated the drag 
via QDrag::exec after the exec returns, then we handle the mouseReleaseEvent 
twice. In the case of the button, it would mean that we emit clicked() if the 
drag is dropped inside the button. Check the following, which simulates that Qt 
would do that. Drag from the button, and drop the drag inside the button. The 
button now emits clicked(). You most certainly don’t want slot connected to 
that signal to execute in that interaction.

This is of course a special case, but it shows that we can’t just start 
delivering MouseButtonRelease events to widgets when a drag operation finishes, 
because they would suddenly execute mouseReleaseEvent code in a state in which 
they don’t expect it to. For instance, QAbstractItemView does not expect to get 
a mouseReleaseEvent when QAbstractItemView::startDrag returns. I didn’t test 
it, but it start the editor of the item that was dragged, which might crash 
when that index got removed by the drag!

Widgets that support drag’n’drop need to reset their state when QDrag::exec 
returns, and must be able to rely that they don’t get a mouseReleaseEvent when 
that mouse release already was processed by the drag’n’drop system to end the 
drag.

Volker


#include 

class DragButton : public QPushButton
{
public:
using QPushButton::QPushButton;

protected:
void mouseMoveEvent(QMouseEvent *e)
{
QDrag *drag = new QDrag(this);
QMimeData *mimeData = new QMimeData;

mimeData->setText(text());
drag->setMimeData(mimeData);

Qt::DropAction dropAction = drag->exec();

// simulate that Qt deliveres a mouseReleaseEvent to the source widget
// after the drag finished.
if (e->buttons() == Qt::LeftButton) {
QMouseEvent *mouseRelease = new QMouseEvent(
QEvent::MouseButtonRelease, e->position(), e->globalPosition(), 
Qt::LeftButton, {}, {}
);
QApplication::postEvent(this, mouseRelease);
}
qDebug() << dropAction;
}

void mouseReleaseEvent(QMouseEvent *e)
{
qDebug() << "mouseRelease" << e;
QPushButton::mouseReleaseEvent(e);
}
};

int main(int argc, char *argv[])
{
QApplication app(argc,argv);

QWidget window;
DragButton button("Drag me");
QObject::connect(, ::clicked, , []{
qDebug() << "Clicked!";
});

QVBoxLayout layout;
layout.addWidget();
window.setLayout();

window.show();

return app.exec();
}

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QPushButton: drag and drop

[Giuseppe D'Angelo via Development]

On 03/06/2022 14:20, Laszlo Papp wrote:
I do not know the details very well, but from a user point of view, it 
would be good to either let mouseReleaseEvent get triggered as usual 
after the dragging has finished or at least not to have artifacts like 
the above around.


I have also noticed several posts on Stack Overflow, Qt Centre, etc, 
about this issue without a "real solution". E.g. this dates back to 12 
years ago: 
https://www.qtcentre.org/threads/34539-Drag-and-drop-from-QPushButton 



What do you think about this issue?


That it's a bug. Did you search for submitted reports or did you submit 
one yourself?


Thanks,

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts


smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development