Re: KGuiAddons and QGestures like tap/click-and-hold to open context menu?

[René J . V . Bertin]

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, or a tristate property.
- set the "grabbed" QObject property to False when a mousebutton release event 
is received. This is a safe alternative to ungrabbing the gesture when we 
cannot know if the object already grabs it.
- generate a mousebutton release event before generating a contextmenu event. 
It might be more ideal to do this only when the object does handle the context 
menu event but then the event order would be wrong.

R

Re: KGuiAddons and QGestures like tap/click-and-hold to open context menu?

[René J . V . Bertin]

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 keeping menus open after a 
single click is implemented by simuling a form of tap-and-hold gesture.
I ought to be able to ungrab the gesture explicitly when I receive a 
MouseButtonRelease event, but can't do that unless I can determine that the 
object didn't already grab the gesture before I subscribed it myself.

R.

Re: KGuiAddons and QGestures like tap/click-and-hold to open context menu?

[David Faure]

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 like that, but didn't get around yet to figuring
> out how.
> 
> Any idea how much overhead that  method comes with? A priori I'd just need
> to store a boolean.

Go for it, it's just one more QVariant.

> Talking about overhead, what would be cheaper, storing the result of a
> dynamic_cast in a temp. variable or calling obj->inherits()? (I could peek
> at the sources and run benchmarks but I'm not convinced it'd be worth the
> time.)

Neither, use qobject_cast.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: KGuiAddons and QGestures like tap/click-and-hold to open context menu?

[René J . V . Bertin]

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 how much overhead that  method comes with? A priori I'd just need to 
store a boolean.

Talking about overhead, what would be cheaper, storing the result of a 
dynamic_cast in a temp. variable or calling obj->inherits()? (I could peek at 
the sources and run benchmarks but I'm not convinced it'd be worth the time.)

R.

Re: KGuiAddons and QGestures like tap/click-and-hold to open context menu?

[David Faure]

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: QObject::setProperty,
which supports dynamic properties so you can store anything you want in there.

(this could also be used to replace m_grabbing, using a different property of 
course)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: KGuiAddons and QGestures like tap/click-and-hold to open context menu?

[Martin Gräßlin]

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 for Plasma on touchscreens though, faking
>a right click on  *touch* long-press. Maybe that's an approach that's
>more pleasing to Martin G than doing that inside KWin which he said is
>the wrong place to do that.

It is not the wrong place, it is technically impossible to do it in KWin.
Generating context menu events must be in the applications. Only those can know 
what makes sense and know whether the touch event is handled or not.

In general I oppose the idea. I think we need to rethink and not emulating a 
decades old pattern, just because we don't have a better idea.
Especially in Plasma I would not like to see this. We can do better.

Cheers
Martin

Re: KGuiAddons and QGestures like tap/click-and-hold to open context menu?

[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 for Plasma on touchscreens though, faking a right 
click on  *touch* long-press. Maybe that's an approach that's more pleasing to 
Martin G than doing that inside KWin which he said is the wrong place to do 
that.

Re: KGuiAddons and QGestures like tap/click-and-hold to open context menu?

[Martin Klapetek]

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 right-click or menu
> button. After all, not all platforms have a (physical) right mouse button
> or a menu key; Macs come to mind but also mobile devices.


> The usual way to open the context menu on such platforms is
> click/tap-and-hold - I think that was actually introduced in an early Mac
> OS X version.
>

Macs however always have two-fingers secondary click;
their magic mouse have both (it's mouse-touchpad hybrid).

Worth noting that the tap-and-hold is used only in very few
places of the macOS shell, like the bottom launcher and
Launchpad, pretty much nothing else accepts tap-and-hold
for context menu, certainly not any of the regular apps.
So I wouldn't say that is "the usual way" on mac at all.

Just to provide some more insight for non-mac folks.

Cheers
--
Martin Klapetek

Re: KGuiAddons and QGestures like tap/click-and-hold to open context menu?

[René J . V . Bertin]

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 intended effects :)

R.

Re: KGuiAddons and QGestures like tap/click-and-hold to open context menu?

[René J . V . Bertin]

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 from scratch in its most basic form isn't difficult, but 
getting all the border conditions right (like what to do when the mouse moves 
out of and back onto the widget) must be tedious at best.

R.

Re: KGuiAddons and QGestures like tap/click-and-hold to open context menu?

[René J . V . Bertin]

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 we'll see about that.

R.

Re: KGuiAddons and QGestures like tap/click-and-hold to open context menu?

[David Faure]

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 platform
> plugin and installed at the application level. But what would be the
> interest of that if no widgets subscribe to a tap-and-hold gesture? Why
> would code grab that gesture if it cannot be certain that the required
> event filter is installed?

Forget QGesture, this can be done with simple mouse events.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: KGuiAddons and QGestures like tap/click-and-hold to open context menu?

[René J . V . Bertin]

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 would be the interest 
of that if no widgets subscribe to a tap-and-hold gesture? Why would code grab 
that gesture if it cannot be certain that the required event filter is 
installed?

R.

Re: KGuiAddons and QGestures like tap/click-and-hold to open context menu?

[René J . V . Bertin]

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 platform integration plugin could be a good place, I'll tinker
> > with that in my osx-integration plugin.

Doh, we forgot something ...

You need to "subscribe the widget to a given gesture with specific flags" using 
QWidget::grabGesture(). I don't see any documented way to enable gestures of a 
given type for all current and future widgets or QGraphicsObjects.

That probably makes it impossible to implement this kind of feature the way you 
were implying, outside of Qt itself. All I see is an implementation in a 
library, where you create a single instance (per application) of a dedicated 
class that contains the eventFilter() function. And a static method that takes 
a QWidget, subscribes it to the gesture and installs the event filter.

R.

Re: KGuiAddons and QGestures like tap/click-and-hold to open context menu?

[René J . V . Bertin]

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 
moving in time the tap-and-hold gesture never completes.

> And then there's the question of the interaction with toolbuttons that have a 
> menu (we want the toolbutton menu to popup, not the event to be automatically 
> transformed into a context menu event which would break the toolbutton menu).
> You can test this with konqueror's back toolbar button for instance.

That's a more delicate issue but I presume it must be possible to test if a 
QToolButton has a menu itself. 

R.

Re: KGuiAddons and QGestures like tap/click-and-hold to open context menu?

[David Faure]

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 slow, more like "oops, forgot to release the mousebutton". 700ms is
> longer than you think - I *know* that and still find I need patience to
> trigger the gesture in its default setting ;)

Or I hold the mouse button pressed because I'm about to start a drag-n-
drop.

And then there's the question of the interaction with toolbuttons that have a 
menu (we want the toolbutton menu to popup, not the event to be automatically 
transformed into a context menu event which would break the toolbutton menu).
You can test this with konqueror's back toolbar button for instance.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: KGuiAddons and QGestures like tap/click-and-hold to open context menu?

[René J . V . Bertin]

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 
longer than you think - I *know* that and still find I need patience to trigger 
the gesture in its default setting ;)

> > something that users might want to control the way they could control
> > certain things via Q4's qtconfig .
> 
> Or systemsettings, sure.

That'd be the KF5 replacement, yes.

R.

Re: KGuiAddons and QGestures like tap/click-and-hold to open context menu?

[David Faure]

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 would
> >then be a generic event handling thing. Off by default though, in that
> >case, at least on systems which do have a right mouse button.
> 
> That sounds logical but one could also argue that it should be on by default
> because it's the single kind of event that an exist on all systems with a
> pointing device.

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.

> 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 platform integration plugin could be a good place, I'll tinker
> with that in my osx-integration plugin.
> 
> FWIW, did you have a look at my implementation?

I didn't. 

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: KGuiAddons and QGestures like tap/click-and-hold to open context menu?

[René J . V . Bertin]

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, in that case, 
>at least on systems which do have a right mouse button.

That sounds logical but one could also argue that it should be on by default 
because it's the single kind of event that an exist on all systems with a 
pointing device.

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 .

Maybe the QPA platform integration plugin could be a good place, I'll tinker 
with that in my osx-integration plugin.

FWIW, did you have a look at my implementation? I currently need to "unpress" 
the button explicitly after sending the contextevent and I have a hunch that 
shouldn't be necessary. Maybe I shouldn't return true after converting the 
TapAndHold gesture event and pretend I never did anything with it?

R.

Re: KGuiAddons and QGestures like tap/click-and-hold to open context menu?

[David Faure]

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 . 
> That class
> wouldn't need this extension then, but I think it's not trivial to use
> QToolButton instead of QPushButton without any side-effects? 

The rendering of the button is slightly different, but that's it.

> (And of course
> my implementation should work with any QWidget.)

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? It would 
then be a generic event handling thing. Off by default though, in that case, 
at least on systems which do have a right mouse button.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: KGuiAddons and QGestures like tap/click-and-hold to open context menu?

[René J . V . Bertin]

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 to use 
QToolButton instead of QPushButton without any side-effects?
(And of course my implementation should work with any QWidget.)

R.

Re: KGuiAddons and QGestures like tap/click-and-hold to open context menu?

[David Faure]

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 button. After
> all, not all platforms have a (physical) right mouse button or a menu key;
> Macs come to mind but also mobile devices.
> 
> The usual way to open the context menu on such platforms is
> click/tap-and-hold - I think that was actually introduced in an early Mac
> OS X version.
> 
> With Qt's TapAndHold gesture this is actually not difficult to implement at
> all, see
> https://forum.qt.io/topic/46738/how-to-simulate-properly-an-long-click-on-t
> he-mouse-on-a-button-updated-with-full-code/10#
> 
> Would this be an idea to add to a framework like KGuiAddons?

Isn't this exactly what QToolButton::setMenu does?
(given that the default popupMode is DelayedPopup)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

KGuiAddons and QGestures like tap/click-and-hold to open context menu?

[René J . V . Bertin]

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 or a menu key; Macs come to 
mind but also mobile devices.

The usual way to open the context menu on such platforms is click/tap-and-hold 
- I think that was actually introduced in an early Mac OS X version.

With Qt's TapAndHold gesture this is actually not difficult to implement at 
all, see
https://forum.qt.io/topic/46738/how-to-simulate-properly-an-long-click-on-the-mouse-on-a-button-updated-with-full-code/10#

Would this be an idea to add to a framework like KGuiAddons?

R.