mouseButton with ALT bug?

GreenCell

Here's something I just noticed. Take this simple example:

void setup() {
}

void draw() {
 println(mouseButton); 
}

if I hold the right mouse button it prints 39. Now if I hold down the ALT key then hold the right mouse button it prints 3. 3 is actually the value for CENTER, so what gives? I should mention that this is in Processing 2.2.1 in Java mode.

KevinWorkman

Looking through the source, we find this logic:

int modifiers = nativeEvent.getModifiers();

    int peModifiers = modifiers &
      (InputEvent.SHIFT_MASK |
       InputEvent.CTRL_MASK |
       InputEvent.META_MASK |
       InputEvent.ALT_MASK);


    int peButton = 0;

    if ((modifiers & InputEvent.BUTTON1_MASK) != 0) {
      peButton = PConstants.LEFT;
    } else if ((modifiers & InputEvent.BUTTON2_MASK) != 0) {
      peButton = PConstants.CENTER;
    } else if ((modifiers & InputEvent.BUTTON3_MASK) != 0) {
      peButton = PConstants.RIGHT;
    }

    sketch.postEvent(new MouseEvent(nativeEvent, nativeEvent.getWhen(),
                                    peAction, peModifiers,
                                    nativeEvent.getX(), nativeEvent.getY(),
                                    peButton,
                                    peCount));

This is where the magic is happening. I'm trying to understand exactly how that results in peButton being set to PConstants.CENTER, but this is a start.

GreenCell

Is this behavior happening on your end as well? Could it be a bug? This doesn't seem to be a problem with processing.js, only in Java mode.

KevinWorkman

Yes it does happen on my end as well. It might be a bug, but since Processing is open source, we have the power to track down the cause of the behavior to really decide whether it's a bug or not.

The next thing to do would be to figure out the value of modifiers is, but that requires modifying the Processing source so it's a little more involved.

quark

It also happens with me on Osx and Processing 3.2.1

GreenCell

I don't think modifying Processing's source code is an actual solution. I reported this on processing's Github. https://github.com/processing/processing/issues/4711

quark

This bug only appears to be with the JAVA2D renderer as it correctly identifies the RIGHT button with P2D (OpenGL)

I have added this to the issue you raised.

GreenCell

Thanks quark!

KevinWorkman

I don't think modifying Processing's source code is an actual solution.

I wasn't saying that we should modify the source code to fix the problem, I was saying we should modify the source code to print out the value of modifiers so we could better understand what's going on.

That being said, how do you expect a solution to be implemented without modifying Processing's source code?

GreenCell

I figured the right action would be to report it to the right people. I hardly feel comfortable changing source code and can't even find the file. But if you think that's the way to go then please help!

quark

Changing the source code yourself is not really an option it is the job is the job is for an experienced software developer. Even then you need to find the cause of the logic error which in this case is not obvious. Reporting it is the right thing to do.

KevinWorkman

I agree that OP should have reported it. I also think that we have experienced developers on the forum who could help track down exactly what's going on.