Re: KGuiAddons and QGestures like tap/click-and-hold to open context menu?
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?
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?
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?
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?
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?
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?
> 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?
On Sun, Mar 12, 2017 at 4:03 AM, René J.V. Bertinwrote: > 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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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