This can be easily achieved by adding a MouseListener that only reacts to the right click. With the current system we can easily opt-in to a behaviour, but no way to opt out from right clicks, so this is all this FR is about.
It is really about change management. You have to suggest changes that are chewable. And for the big unicorn please make a new thread!
This part seems to completely forget that buttons are mainly used to trigger actions, for example “Save”, “Load”, “Close”, etc.
There are no values associated with those actions.
In your proposal above you seem to have in mind a very specific use case, i.e. a button that acts as a boolean switch for a plug-in parameter. But buttons have a much broader use than that…
…and this seems to completely forget that the listener mechanism is necessary to achieve one-to-many, many-to-one and even many-to-many relationships. It’s something that cannot be as easily replicated with the onClick lambdas. Even if not used frequently, it has its use cases and removing it represent a change that goes beyond breaking IMHO, without adding anything useful to the codebase
How about simply adding the onRightClick lambda? Leave the onClick alone as the “left click” solution. This is non-breaking and opt-in by default.
The problem isn’t to opt-in, but to opt-out.
You can easily add a reaction to a right click with a MouseListener. But you cannot avoid that e.g. the ComboBox reacts to the right click as well.
That doesn’t solve the problem, because it still assumes that the button has an action associated with a click with the right mouse button, hence it would still retain the “press/release” animation, whereas my request for ignoring the right mouse button is to avoid that.
Besides, it is still a breaking change (albeit subtle) because for the (few) users that expected the right click to behave exactly as the left click, this would stop being the case
Ahh…point taken. And it makes sense to expect the different behavior. I ended up creating my own button class and slider class (not derived). I wanted much simpler behavior and more control over the actions. FWIW, I implemented onLeftClick and onRightClick lambdas just so I can decide what they do.
Perhaps the JUCE team has some ideas?
nope. it would look like this. so basically just like it already is. just a state-less click event:
button.onClickLeft = [&]()
{
presetBrowser.savePreset();
};
you mean like radiobuttons and stuff, where one component needs to react to another component’s change, right? i have done these with onClicks before. I don’t see the problem
And you continue to ignore all use cases that you don’t need. We have complex hover behavior, components overlapping each other that still need to highlight the parent component, drag-drop behavior, etc. and it needs the various listener callbacks to work.
Please don’t assume that you have all the answers. There are too many variables to consider. The current system is fine, it just needs a couple of additions, not throwing it all out.
it rather looks to me like you all are ignoring the edge cases. for example daniel’s perspective, where it’s easier to add functionality with the listener than to hack around the rightclicks rn, doesn’t consider that if you only slap a listener on top of your button it will not have the same visual click behaviour/animation if the base class says right clicks are ignored. (considering there are animations. it doesn’t seem to be a thing in buttons yet, but that is really a topic for another day)
I think what this FR is asking for is basically to add to juce::Button something like:
void setAllowRightClicks (bool allowed);
this would be on by default and if you pass false, then onClick and listeners don’t get called for right-button clicks.
Simple, small, non-breaking change.
For right-click behavior, you don’t need to add any listeners. You simply override the mouseDown and/or mouseUp functions, check for a right-click there, and either call the base-class or implement your context-menu (or other right-click behavior) there.
The problem is really not with the Component, but with all subclasses, that have mouseDown implemented. They should have the possibility to ignore non-primary mouse clicks, and it is best implemented in the base class juce::Component. Simple.
Have mercy, and if it’s just to end this discussion 
One of the most popular feature requests with 50 votes. Almost 8 years old… is it getting close to the top of the priority list yet?
I guess people just took their votes away \_O_/
So we are still not getting this feature?
