> 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
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
> 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)
>
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
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
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
>> 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
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
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
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
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
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
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
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
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
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
> 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
> 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
> 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?
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
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
> 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
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
> 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
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
25 matches
Mail list logo
