Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IMouseMod.L always true on MacOS #1021

Open
janhase88 opened this issue Nov 9, 2023 · 1 comment
Open

IMouseMod.L always true on MacOS #1021

janhase88 opened this issue Nov 9, 2023 · 1 comment

Comments

@janhase88
Copy link

janhase88 commented Nov 9, 2023

Issue Description

The getMouseLeft function in IGraphicsMac_view.mm incorrectly sets the left mouse button state to always true, regardless of its actual state.

Expected Behavior

The function should accurately reflect the real state of the left mouse button.

Observed Behavior

Regardless of the actual mouse state, info.ms.L is set to true.

Proposed Fix

Modify the function to assess the NSEvent type to determine the left mouse button's state.

Suggested Change

- (IMouseInfo) getMouseLeft: (NSEvent*) pEvent {
    IMouseInfo info;
    [self getMouseXY:pEvent : info.x : info.y];
    int mods = (int) [pEvent modifierFlags];

    info.ms = IMouseMod(([pEvent type] == NSEventTypeLeftMouseDown) || ([pEvent type] == NSEventTypeLeftMouseDragged),
                        (mods & NSCommandKeyMask),
                        (mods & NSShiftKeyMask),
                        (mods & NSControlKeyMask),
                        (mods & NSAlternateKeyMask));

    return info;
}
@AlexHarker
Copy link
Collaborator

Thanks for the report.

This looks like it needs wider checking than the PR as it also affects getMouseRight and we need to ensure parity with windows. There might be some discussion to be had about what should happen for mouseups for instance (as this is a possible mechanism for a dev to differentiate left/right mouse ups. It would also be a little bit of detective work to figure out what was happening before I made the restructure that introduced these methods.

The PR looks like a sensible proposition as a starting point, but we need to ensure consistency. (As a more minor matter, PRs that match formatting are easier to merge directly and in this case the opening curly bracket has been moved on the method)

This issue relates to #635 and they should be resolved together

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants