[Development] QPushButton: drag and drop

Laszlo Papp lpapp at kde.org
Fri Jun 10 06:28:02 CEST 2022


On Thu, Jun 9, 2022 at 4:20 PM Volker Hilsheimer <volker.hilsheimer at qt.io>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20220610/1c272168/attachment.htm>


More information about the Development mailing list