feature request: +/- buttons for knobs

[colren]

I'm wondering if it's possible to get the little + and - click boxes on each side of the rotary controls like the EQs and Gain functioning? At the moment if you are only using a mouse making slight adjustments to the EQ or gain is quite difficult and can result in some very audible mistakes.

A friend who uses Traktor was laughing at me while watching me adjust EQ and showed me how he does it on Traktor (clicking on the little boxes each side of the rotarys) and the funny thing is that the boxes are there in Mixxx (LateNight theme) but they don't work.

>The Control Objects are there and can be mapped to keyboard keys, but >putting buttons for that on screen would clutter the interface. If we could >make those buttons only appear when the mouse is hovered over the knobs, >that could work. The skin system doesn't currently support showing/hiding >widgets on mouse hover, but it could be possible to modify it to do that. >Please open a feature request/bug report so this does not get forgotten.
>
>I am not sure what you are talking about with LateNight. There are no +/- >buttons next to the knobs. There are little indicators to show the ends of >the knob's range, but those aren't buttons.
>
>FWIW, you can use mouse scrolling to adjust knobs/sliders in Mixxx when >your cursor is over them.

Hi, yeah the little indicators at the ends of the knobs range is what I mean. In Traktor these acts as clickable micro-adjustment controls for the EQ and Gain as hovering over the knobs and scrolling with the mouse is too haphazard/in-accurate. It's a bit hard to describe but if you try in on Traktor you will know what I mean. :-)

[colren (colren)]

Hi,

Just added this here to keep it current. First mentioned here:

http://www.mixxx.org/forums/viewtopic.php?f=1&t=8759

col.

[ronso0 (ronso0)]

I'd like to implement this feature. And if I do so, it would make sense to have it on ALL knobs.
Then, it would be simple if all knobs have a common template with <Variable name="Size", I think.

I'll do a PR when it's working for EQ, then open discussion about the rest there.

[ronso0 (ronso0)]

@colren Just to make sure since I don't have Traktor: you expect those buttons to turn the knob a small step when clicked, right? Press&hold for a continuous turn won't be possible AFAIK

[colren (colren)]

Hi Ronso0, yes that would be perfect!
cheers

[Daniel Schürmann (daschuer)]

Some Infos:

The Knob widgets are defined here:
https://github.com/mixxxdj/mixxx/blob/master/src/widget/wknobcomposed.cpp

It sounds like we are heading to a redesign of this knob.

I see two options:
* Allow to define child widgets for a Knob widget like in WidgetGoup
-> this is th most flexible solution, but probably hard hard to setup in skins.
* Just define sensitive regions that automatically works as desired when the knob is bound to a ControlPotmeter.
-> Easy to setup, and we are able to handle all events and probably odd corner cases in one widget.

You should alwasy consider touch screens as well. Maybe we are able to fix this bug on the go:
https://bugs.launchpad.net/mixxx/+bug/1217738

Here are some more touch infos:
https://bugs.launchpad.net/mixxx/+bug/1152572

What do you plan?

[ronso0 (ronso0)]

Ummmm, I was actually thinking about doing it at skin level:
making any knob.xml a stacked layout and stacking two buttons on top. This way, I'd to position the buttons individually for every knob size with <Pos> or margin.

You're seeing a bigger picture I guess...
I had a look at wknobcomposed.cpp and wwidgetgroup.cpp
If I get it right (?), your 1st suggestion is basically like mine but on another level (WKnobComposed::addWidget?) so that one would have
<KnobComposed>
   <Background>...
   <Indicator>...
   <Children>
     <LeftButton>(incl. object name, conneceted control, ...
     <RightButton> --"--
   </Children>
And "hard" means your worried about the positioning per knob type with qss?

In your 2nd suggestion "sensitive regions" refers to relative positioning and sizing of buttons as well as an interface to individually connect controls in knob.xml, both on C++ level?
To maintain some flexibility, couldn't size and position (top/bottom) be variable, too, then?

In case I got it right, I like the second idea much more!
But I'd need 'a few' hints how to accomplish this.

Regarding the touch bugs: I'm still C++ newbie, so a lot can happen on the go... ;)

[Daniel Schürmann (daschuer)]

> And "hard" means your worried about the positioning per knob type with qss?

With hard I mean, the Skinner has to worry about the additional widget connections and button styles. But he has the freedom to do it in a fancy way ...

In the second Idea, we have only knob style as it is and a new pos and size element.

<KnobComposed>
   <Background>...
   <Indicator>...
   <IncreaseButton>
     <Pos> ..
     <Size> ..
   <DecreaseButton>
     <Pos>
     <Size>

In the C++ level you "just" have to treat clicks to these regions individual.

[Be (be.ing)]

Perhaps a good way to avoid cluttering the interface would be to only show these +/- buttons on mouse hover. That won't work on touch screens though. Is Qt able to detect whether the screen is a touch screen in a reliable cross platform way?

[ronso0 (ronso0)]

Two things I'd like to add:
1. @colren refers to the default LateNight skin where those possible 'button areas' aleardy exist, call it cluttered or not. If this is realized along @daschuer's first proposal default/hover appearance could be styled per skin.
2. Those buttons would be tiny, so I doubt that they would really be useful. I only have experience with 10" capacitive touch screens running debian/xfce, so correct me if I'm wrong.

I throw in another idea for touchscreen context:
single-short clicking any potmeter toggles a semi-transparent overlay where lower half would be buttons [-] and [+] next to each other, upper half would be a 'close' button to return to standard potmeter view. This toggler could affect all or only the clicked potmeter.

[ronso0 (ronso0)]

 > so I doubt that they would really be useful
...on touch screens.

Freeing this up, probably won't start on this very soon.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/8731