perphaps it should be implemented at the Component level, like setInterceptsMouseClicks.
I’m not a fan of this idea beacuse that would defeat the purpose of my original request: a button that should trigger its click events when left-clicked, but that should display a pop-up menu when right-clicked.
If such an hypotetical setInterceptRightClicks() were implemented at Component level, then it’d be impossible to receive right-clicks at all to trigger the menu.
Unless, right clicks were still forwarded to registered MouseListenersand only their “internal” handling were ignored, but that feels a little too “fragile” to be reliable
1 Like
Bump for an official response from the JUCE team?
1 Like
+1 please consider this. JUCE is the only UI system where buttons activate on right click. macOS, Windows, Linux, etc buttons do not activate on right click. And there is no easy way to work around this, I posted another FR to be able to get the ModifierKeys in onClick() so at least you could test if was a right click.
8 Likes
Ideally you’d want something like an event filter to intercept arbitrary events being passed to children. I think this is a much better request than a special case for ignoring clicks.
But either way you could have a pair of components, one as a container for the children whose events are intercepted and the context menu as a sibling of the container.
2 Likes
Totally. It would add so much more flexibility to the Component system, especially with use cases like the one @RolandMR mentioned where you’d want to customize the events for a reusable Component like juce::Button for a specific use case.
I’ve been only been experimenting with it so far but the druid framework has an elegant way of doing this, where you can assign a Controller to widgets and use it to determine which events get passed on to its children. It would be very useful to have a similar abstraction in JUCE, when you don’t actually want to make a component, but encapsulate one and modify its behavior by intercepting events destined for its children. Something that makes that tricky in JUCE today is that it doesn’t have a generic event dispatch method, everything is a virtual method.
I’m dealing with this nightmare right now, I can’t believe after all of these years that a simple mechanism hasn’t been added to filter between left/middle/right clicks in the button class. Why is there resistance to adding such a common/necessary feature? I don’t get it.
1 Like
The JUCE team doesn’t like new features like that. It’s apparently too risky (breaks existing apps that rely on old behavior) and apparently not worth the effort.
We naturally completely disagree about these tiny features. This is something that can be implemented and tested within 30-60 minutes, even retaining backward compatibility without losing ANYTHING—zero risk. Happy users.
But that’s for them to decide…
3 Likes
I’m tempted to think up a car analogy…
No ROI no gain
I have been keeping an eye on this one for a while. I’m not normally a fan of adding more and more features to our widgets but I think this seems sensible and clearly popular enough to warrant taking a look at. I’ll try and see what I can do soon but there’s a few bugs on my plate right now.
7 Likes
Adding my solidarity to this thread. Like many others, my aim is to have context menus that appear on right click of a button without activating that button.
Currently I’m using this template approach as a workaround, but it’s a clunky hack for something that I feel should be default behavior.
I can’t think of a single GUI I’ve used where right-clicking a button performs identically to left-clicking a button.
1 Like
ideally the developer who implements the button should have the option to decide what happens on each type of mouse click. generally both button and slider should become more flexible in their behaviour. Slider still has no sensitive mousewheel, no way to change the sensitive modifier to shift and no way to adjust how strong each drag or wheel event moves the knob (basically no control on the feeling), dropdown menus’ buttons have no mousewheel support etc, forcing me to write my own components for the most basic things all the time.
I think the event filter idea could be a huge feature for JUCE and a non-breaking change as well. Perhaps a new FR for that should be opened?
1 Like
I don’t know how the event filter would look like, but thinking of QEventFilter makes me shiver!
Maybe if done properly with RAII it could be something, but QT is nothing to look up to in that respect.
But in real code the QEventFilter always looked like hiding a design problem.
A similar problem to the above can be encountered if a viewport can be scrolled by dragging and contains gui elements.
In the case of a viewport, you want the user to be able to drag-to-scroll anywhere on that vieport without the buttons or other gui elements being triggered.
Currently, to implement the above one has to jump through many hoops. Wouldn’t an event filter be a good general approach to tackle such a problem?
1 Like
yeah, but i want all of the features I just mentioned, not just one of them. Funnily I just beta-tested another plugin that highlighted multiple of these problems. The developer has a few controls there that feel great on mousewheel, because they are sliders with choice parameters. but the controls look like they should be buttons and we all know if they were buttons they would be clickable, but they wouldn’t have a nice scrollwheel behaviour. the JUCE default widgets need way more control on the implementation side. not just a bit of this and that, a lot more!
I tend to think that all JUCE widgets known for years should be left as they are, otherwise there will be an endless debate about breaking changes. Instead, maybe a solution is to implement just new improved versions called TextEditor2 or TextButton_V2 like we have LookAndFeel_V2 / V4? Another thing is I cannot even remember when some new widget appeared in JUCE 
4 Likes
Oh please, let’s not stop there. Let’s also append Ex to make it TextEditor2Ex for when there are subtle changes to the APIs: this involves a copy/paste and rename of the class though. We can’t make it more confusing. Might as well convert all of the Components to COM.