Congratulations to Jonas. Approver status has been granted.
--
Alex
From: Development on behalf of Oliver
Eftevaag
Sent: Thursday, 12 May 2022 13:23
To: development@qt-project.org
Subject: Re: [Development] Nominating Jonas Karlsson as maintainer for
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
Hi again,
I hope you are all doing well.
Sorry for the spam! - here is one of my last pre-event e-mail messages. :)
BigBlueButton links to access our virtual event:
Jun 7: https://meet.kde.org/b/qtcs2022-jun7
Jun 8: https://meet.kde.org/b/qtcs2022-jun8
Break-out rooms can be created ad hoc.
Our
For a example:
WaylandOutput {
WaylandClientSurface {
...
}
Button {
...
}
}
In the WaylandOutput, its have two item. The first item is a
WaylandClientSurface, its will report the damaged area of the surface to
wayland compositor from the wayland client when the
Hi!
Qt 6.4 Feature Freeze will be in effect today. If your change(s) are ready &
approved today but fails to integrate due to CI flakiness etc you can still
continue staging those in 'dev' during the weekend; we are planning to branch
'6.4' from 'dev' at the beginning of next week. But if your
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
> 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 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 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
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
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
11 matches
Mail list logo
