This actually works pretty nicely:
https://commits.kde.org/scratch/rjvbb/osx-integration/1bfc3c00293dff6c726d0853457ab09b560e3df9
- m_grabbing is still used to track whether the 1st mousebutton press must be
resend after grabbing the gesture. I prefer that to using a separate object
property,
Either way it remains tricky business doing this without any knowledge about
the widget that's being grabbed. I've already seen cases where you open a menu
with a single mouse click and then the context menu appeared as well a short
while later.
That looks as if even the standard behaviour of
On mercredi 15 mars 2017 09:27:28 CET René J.V. Bertin wrote:
> On Wednesday March 15 2017 09:07:48 David Faure wrote:
> >Definitely. But there's another solution: QObject::setProperty,
> >which supports dynamic properties so you can store anything you want in
> >there.
> I did think of something
On Wednesday March 15 2017 09:07:48 David Faure wrote:
>Definitely. But there's another solution: QObject::setProperty,
>which supports dynamic properties so you can store anything you want in there.
I did think of something like that, but didn't get around yet to figuring out
how.
Any idea
On dimanche 12 mars 2017 23:40:29 CET René J.V. Bertin wrote:
> Proof of concept:
>
> https://commits.kde.org/scratch/rjvbb/osx-integration/1260a608db98cfd3d75bf1
> 5917945b59c81b1182
" storing all grabbed QObjects is potentially dangerous "
Definitely. But there's another solution:
Am 13. März 2017 16:15:34 MEZ schrieb Kai Uwe Broulik :
>
>> Macs however always have two-fingers secondary click; their magic
>mouse have both (it's mouse-touchpad hybrid).
>
>If all else fails you could still Control click on Mac iirc.
>
>This feature would be useful
> Macs however always have two-fingers secondary click; their magic mouse have
> both (it's mouse-touchpad hybrid).
If all else fails you could still Control click on Mac iirc.
This feature would be useful for Plasma on touchscreens though, faking a right
click on *touch* long-press. Maybe
On Sun, Mar 12, 2017 at 4:03 AM, René J.V. Bertin
wrote:
> Hello,
>
> The other day I had to add a context menu to a widget (QPushbutton)
> defined in a .ui file and went a bit further when I realised it could be
> nice to be able to open such a menu without using a
Proof of concept:
https://commits.kde.org/scratch/rjvbb/osx-integration/1260a608db98cfd3d75bf15917945b59c81b1182
The same class also adds a simulated (emulated?) Menu key that's a real saver
in those situations where I'm getting more side-effects from my trackpad's
2-finger right-tap than
On Sunday March 12 2017 20:21:33 David Faure wrote:
> Forget QGesture, this can be done with simple mouse events.
Another solution: catch mouse events for the desired QWidget types, use
QGesture::grabbedGesture to check if they are subscribed and if not subscribe
them.
Re-implementing this
On Sunday March 12 2017 20:21:33 David Faure wrote:
>Forget QGesture, this can be done with simple mouse events.
Reinvent the wheel? Why not. I got the impression from the google results that
led to finding the TapAndHold gesture solution that it could be trickier than
you might think but
On dimanche 12 mars 2017 20:14:20 CET René J.V. Bertin wrote:
> On Sunday March 12 2017 20:11:08 René J.V. Bertin wrote:
> > And a static method that takes a QWidget, subscribes it to the gesture and
> > installs the event filter.
> Correction: the event filter could of course be provided by a QPA
On Sunday March 12 2017 20:11:08 René J.V. Bertin wrote:
> And a static method that takes a QWidget, subscribes it to the gesture and
> installs the event filter.
Correction: the event filter could of course be provided by a QPA platform
plugin and installed at the application level. But what
On Sunday March 12 2017 17:52:25 David Faure wrote:
> > And if you make it an optional feature in the QPA it (almost?) becomes
> > something that users might want to control the way they could control
> > certain things via Q4's qtconfig .
>
> Or systemsettings, sure.
>
> > Maybe the QPA
On Sunday March 12 2017 18:57:23 David Faure wrote:
> Or I hold the mouse button pressed because I'm about to start a drag-n-
> drop.
One for which you wait too long then, something users of systems where
tap-and-hold is usual (i.e. most of us?) would probably recognise. If you start
On dimanche 12 mars 2017 18:38:04 CET René J.V. Bertin wrote:
> On Sunday March 12 2017 17:52:25 David Faure wrote:
> > It would trigger, sometimes against the user's will if he's a bit slow, on
> > desktop systems where it's really not necessary since there's a right
> > mouse button.
>
> Quite
On Sunday March 12 2017 17:52:25 David Faure wrote:
> It would trigger, sometimes against the user's will if he's a bit slow, on
> desktop systems where it's really not necessary since there's a right mouse
> button.
Quite slow, more like "oops, forgot to release the mousebutton". 700ms is
On dimanche 12 mars 2017 17:37:55 CET René J.V. Bertin wrote:
> On Sunday March 12 2017 16:54:20 David Faure wrote:
> >If it's about a very general long-click-should-open-context-menu then maybe
> >it can be done globally in the QPA rather than in each and every widget?
> Probably, yes.
>
> >It
On Sunday March 12 2017 16:54:20 David Faure wrote:
>If it's about a very general long-click-should-open-context-menu then maybe it
>can be done globally in the QPA rather than in each and every widget?
Probably, yes.
>It would
>then be a generic event handling thing. Off by default though,
On dimanche 12 mars 2017 15:46:07 CET René J.V. Bertin wrote:
> On Sunday March 12 2017 15:27:43 David Faure wrote:
> > Isn't this exactly what QToolButton::setMenu does?
> > (given that the default popupMode is DelayedPopup)
>
> Possible, one would indeed expect that from the description .
>
On Sunday March 12 2017 15:27:43 David Faure wrote:
> Isn't this exactly what QToolButton::setMenu does?
> (given that the default popupMode is DelayedPopup)
Possible, one would indeed expect that from the description . That class
wouldn't need this extension then, but I think it's not trivial
On dimanche 12 mars 2017 09:03:51 CET René J.V. Bertin wrote:
> Hello,
>
> The other day I had to add a context menu to a widget (QPushbutton) defined
> in a .ui file and went a bit further when I realised it could be nice to be
> able to open such a menu without using a right-click or menu
Hello,
The other day I had to add a context menu to a widget (QPushbutton) defined in
a .ui file and went a bit further when I realised it could be nice to be able
to open such a menu without using a right-click or menu button. After all, not
all platforms have a (physical) right mouse button
23 matches
Mail list logo