[FR] Buttons: add option to ignore clicks with right mouse button

Feature Requests
41

i’d rather have the JUCE team making more widges with improved behaviour with new numbers at the end of the name than them being afraid to touch the code to ensure backwards compatibility when mousewheel movements still feel bad in 2024, even though this problem was already solved before JUCE existed.

another idea: whenever a class has gained a high popularity over many years and objectively outperforms the older classes in almost every way the old objects can be deleted and people with old projects have to update them finally.

so say there is Slider, with all the things that are missing, then there’s Slider2, Slider3, Slider4, all different attempts at fixing it, but only Slider4 really nails it, so we’d go back to just having Slider, which would be what was Slider4 before. So now new ideas would become Slider2 again. That way the code will not become cluttered despite a system that encourages rewriting stuff a lot.

forum polls can be used to find out which objects are most popular

1 Like
42

What you’re suggesting is a cop-out to actually biting the bullet and using a proper UI system. Instead of bizarrely named classes that give absolutely no clarity to the difference between 1, 2, Ex, etc I’d much prefer seeing what JUCE 8’s web view related stuff has in store. Or use RN or something else for front-end.

43

A namespace might be nicer - e.g. juce::v2::TextEditor.

Personally I rather see the JUCE team work on adding support for native widgets than re-inventing custom widgets. IDK how feasible that is though, I imagine not very.

The idea of a new set of widgets built for JUCE sounds like an excellent 3rd-party community-driven FOSS project. I’d love to contribute to something like that if someone wants to take the initiative to get it rolling.

6 Likes
44

sliders and buttons are the heart of the interaction between the user and the computer in a plugin. they are like what tires are to race cars. the most important thing. so we need fine control on that

45

anthony already said he doesn’t like the idea to add more features to existing widgets. that’s why i wanted to express an alternative solution in which we see faster improvements without breaking old code. i like the namespace idea btw

46

Apart from sarcasm and prosthetics in the form of RN or web interfaces, can you offer anything specific? :wink:

I am talking here about the situation when certain implementations are already hard or impossible to change for many reasons, and when even trivial additions or modifications can create some turmoil. And - in my opinion - that’s the case of many JUCE widgets. They are good but they also show their age, sometimes peculiarities and limitations. It is like when std::auto_ptr was made obsolete and std::unique_ptr introduced instead, etc. I don’t want to focus on semantics. Be it TextButton2 or NewTextButton, whatever. A separate namespace is ok, too. If the naming system is uniform and logical, it does not matter that much.

2 Likes
47

I muddled my own point but this is exactly the motivation to what I said. So let me clear things up and I’ll happily put the sarcasm aside: instead of hacking JUCE classes or copying them to add more specific changes for the few use cases, regardless of their class names, it seems to me that one should wait for the web view related work to come into play, or at least investigate a long term solution like RN.

Modifying JUCE’s UI system to do all sorts of new things is not worth the time IMO, even if it satisfies requests like disabling right click.

48

oh damn, i didn’t even notice you were being sarcastic about the webview stuff. thought since it was a popular topic nowadays you just want it to be done more than “boring” buttons and sliders. that wouldn’t have been too crazy. a lot of people have a mindset like that. fancy features attract more customers than bug fixes and solid old features. just look at bitwig: most innovative features. crappiest cpu performance. i’m personally more on the basic-features-side. not everyone makes an AI-powered plugin or a web service. but almost everyone uses buttons and sliders, so they should be absolutely flawless.

49

For me one of the biggest advantages of JUCE is almost complete independence on external libraries and frameworks, especially when comes to UI widgets. That’s why I don’t think that RN or web renderers could be direct replacements. I consider them rather as parallel alternatives and as such - most welcome!

At the same time I feel that a lot of existing JUCE widgets require some improvements / modifications, which are anyway very often being implemented by users internally. I am talking here mostly about buttons, sliders, text editor (this one is promised for JUCE 8, if I remember correctly), menus and also ListBox, where we have kind of unusual coupling between view and model.

2 Likes
50

Do they still render their UI in Java?

1 Like
51

Misunderstanding here! I was being sarcastic about the naming of the classes.

I’m very pro-webview or RN.

52

The list is pretty long hence why I think it’s not worth the effort to modify/extend/update them, and instead adopt web or RN alternatives (even if it comes with dependencies).

The advantage there is complete flexibility over the look and feel without the hassle of editing JUCE or waiting around for something suitable. In other words, you can modify globally all UI and UX bits to suit your needs within your app itself all the while having the modern equivalents of everything. I realise JUCE 8 promises many updates and upgrades - animation and better text support - obviously what this means remains to be seen, but it’s still 10 years late in terms of what you can do with apps nowadays.

53

oh^^ so I understood you correctly the first time, ok. Well yeah, I’m not against webviews or anything. But if you asked me what should be done first, webviews or widgets, I’d say widgets. I don’t think I’ll ever make a website with JUCE. What’s the point? Even the standalone DAWs already struggle to withstand the complexity of my audio projects on my really good performing computer. Why would I give them an even harder time by putting them into a browser as a web application? Sounds to me like a rather niche problem compared to something that is present in almost every single audio application

54

He means that we should use web views for our plugin UIs. I’m afraid I have to disagree. The overhead, dependencies, complexity, and file sizes are enormous. Communicating real-time data (FFT displays, scopes, sample data, etc.) back and forth across some janky JavaScript engine is a pain.

Imagine the web-views Javascript engine gets an update, and suddenly, the functions you wrote to update some UI display are no longer working. You’ve changed absolutely nothing in your code, but the user updated from Ventura to Sonoma or Windows 11 to Windows 12, and suddenly, part of your Javascript code stopped working. Or they drop some technology (OpenGL to WebGL), and your displays that relied on HW acceleration are suddenly empty. Linking your program to external, opaque code is not a smart move.

Now you have to update your code, and detect the difference at runtime, so you can have the same plugin running on both OS versions. Or you have to create multiple versions of the plugin, depending on the OS version you install. Either your installer needs both versions, or you must rely on the customer to download the correct version. But what if it was installed already, and then the user updates his OS a month later? He would need to run the installer or even download your plugin to make it work. It’s a huge uncertainty and should be avoided at all costs.

In my experience in this industry, every time we’ve licensed some lib (no source code available, link to the *.lib), it has come to bite us in the backside. A new platform came out (PowerPC to Intel, then to Arm), and you will have to patiently wait until they hopefully give you an updated *.lib. We had weird bugs, but no way to debug them, and the developers assured us they didn’t do anything weird; once they relented and gave the source code to us, it turned out they did indeed do a few weird things that caused the bugs.

Dependencies should be avoided as much as possible. If you have to have them, the source code should be available to you to make the necessary fixes/changes.

I think fixing the behavior of a few widgets is a low-cost, easy-to-do (even in a non-breaking way), and worth the effort.

12 Likes
55

I see this has resulted in a lot of discussion that has greatly grown in scope since my initial feature request (which is seven years old now, wow!)

All I wanted to request was for the buttons to ignore the right mouse button, and I still stick to my request because it is “one small change for a man, one giant feature for the whole JUCE community”.

While I am all for organic changes throughout the whole codebase when such needs arise, I don’t think we are at a point where a clear winning strategy has emerged yet, that can point the development of JUCE UI widgets in a new direction to solve all the other requests that have been raised here.

4 Likes
56

I’m mostly with you, but instead of ignoring right clicks I’d suggest we just let every developer decide for themselves what left and right clicks should do. there could be onClickLeft and onClickRight functions. and the parameter attachments could have a new argument for that too with a default option that results in right clicks being ignored. That’s how I’d write it if it was my code base and it shouldn’t be too hard

1 Like
57

That would still require a substantial change to the JUCE code base.

The scope of my request is even smaller: give us library consumers the opt-in possibility to make the Button clickable with the left mouse button only. That’s what I meant with “ignore right button”.

With that in place, it would be up to the library consumer to react to right mouse button the way they want, e.g. attaching a MouseListener or subclassing Buttons to add a lambda like you mentioned.

2 Likes
58

I think we should get rid of ButtonListeners and SliderListeners altogether (or at least call them deprecated in the docs), because one of the things that confuses JUCE newbies most is that some of the most basic tutorials tells them to use those listeners, even though you quickly need to switch to attachments anyway, once you notice in a plugin the actual parameter is decoupled from the widget. I think a lot of people would agree with me that it’s almost always better to decouple the data from its view, so we shouldn’t listen to button changes, but to value changes, and then let the buttons and whatnot react to those. MouseListeners are even worse than the other listeners, because they don’t even know what a button or slider is. They are the most lowlevel listeners and are mostly implemented on the framework backend. I personally never had to use them so far, even though I rewrote a lot of basic UI functionality for my plugins.

In the end the goal is to have an interface that makes it easy to develop the software. I always try to imagine this “backwards”. What should the function you have to call at the end of the day look like? In this case I’m talking about the attachments. I know, not every button or slider is linked to a parameter, but since the attachments are used most of the time and make the problem a little more complicated, I’d see them as the things that should drive the design, if that makes sense.

According to the docs the ButtonAttachment has 3 arguments.

  • apvts
  • parameter ID
  • the button

Questionable why it needs to know about the whole apvts when it’s just about one parameter from it, but ok. (Also why does it lack the undo manager that we have in ParameterAttachment itself, but also ok.)
We could imagine another argument here and this argument would either be in the form of an enum class for the type of thing that is happening on right clicks or the ability to enter a lambda for that action.

enum class RightClickEventType { Ignore, IncreaseValue, DecreaseValue, DefaultValue };

this would limit the functionality to what the JUCE team thinks people want as rightclick behaviour, but it would make it easy to implement the parameter widget and it’s easily extendable in the future. if however the user has to include their own function, even if optional, there is more work and understanding of the underlying structure involved, which could be slightly annoying. But we already have exactly such a system on the parameter construction itself, with the normalisation, denormalisation, stringFromValue and valueFromString functions and I’m pretty sure everyone likes this kind of control, so it could work here as well.

Deriving from these thoughts: that’s why I propose the buttons of have onClickLeft and onClickRight lambdas in them instead of just a bool for ignoring right clicks

59

You are missing the new ButtonParameterAttachment which does exavtly that. It works without the APVTS.

But I would support @yfede to leave this FR alone with all the possible solutions with a complete overhaul.
If the juce team wishes to discuss an all new gui system they will or will not let us know.

This will only happen, when the change is limited to an option to opt-in to only react to the left button / primary button.

2 Likes
60

Yeah I know it seems a bit hard to suggest big changes to solve something small, but this will only bring up the topic again soon. One day someone will come up and say “hey, why can’t I define myself what a rightclick does?” and then it has to be solved again. So that’s why I’d say better solve it at the root of the problem and then enjoy eternal silence on that topic