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

fix #185056: hard to enter notes above/below staff + collect_artifacts #6285

Merged
merged 1 commit into from
Aug 26, 2020

Conversation

MarcSabatella
Copy link
Contributor

Resolves: https://musescore.org/en/node/185056

Currently, when you click to enter a note in note input mode,
and you click a location between two staves or systems,
we try to guess which you mean using a simple split point
located half way between the staves or systems.
This makes it hard to enter notes far above or below the staff,
because at some point we think you mean a different staff.
This comes up all the time for piano music and also guitar,
especially guitar+tab.

My fix here is simple, I prefer the current system and staff.
Current meaning, the one where the note input cursor is.
I let this staff take 75% of the stave above and below,
instead of only 50%.
Thus, clicking far above/below the current staff
will still enter notes onto that staff until you get much closer
to the adjacent staff.

The code is based on existing code that already does the same thing
when choosing which system (and hence measure) to use.
One slight issue that I'll call a "feature" for now:
the existing code for preferring a system cannot be configured
as to how much to prefer it.
So instead of the current system taking 75% of the space above/below,
it takes 100%.
I think this is fine, it's much more common to be flipping
from staff to staff within a system than flipping from system to system
when entering notes,
so it makes sense we try even harder to prefer the current system.
You can of course still enter notes onto the system above or below,
if you click directly on the staff,
or move the note input cursor.

@Jojo-Schmitz
Copy link
Contributor

Jojo-Schmitz commented Jul 5, 2020

That AppVeyor fail seems due to a recent update to a newer MSVC compiler on the site together with a Qt Bug. See https://t.me/musescoreeditorchat/78898
See #6294
Edit: that got merged, so rebasing should fix that failure

Resolves: https://musescore.org/en/node/185056

Currently, when you click to enter a note in note input mode,
and you click a location between two staves or systems,
we try to guess which you mean using a simple split point
located half way between the staves or systems.
This makes it hard to enter notes far above or below the staff,
because at some point we think you mean a different staff.
This comes up all the time for piano music and also guitar,
especially guitar+tab.

My fix here is simple, I prefer the current system and staff.
Current meaning, the one where the note input cursor is.
I let this staff take 75% of the stave above and below,
instead of only 50%.
Thus, clicking far above/below the current staff
will still enter notes onto that staff until you get much closer
to the adjacent staff.

The code is based on existing code that already does the same thing
when choosing which *system* (and hence measure) to use.
This code exists for things like dragging line handles.
One issue is that the existing code actually went all out
in preferring a system - claiming *all* of the space
up until the next system.
So I modified that existing code to take an additional parameter
to control the spacing factor for preferred staves,
defaulting to 1.0 so the exisitng use cases are unaffected
(and I checked the math carefully to be sure the effect is the same).
@MarcSabatella
Copy link
Contributor Author

Indeed, thanks! I also went ahead and updated it to fix something that bothered me about the original implementation.

@anatoly-os
Copy link
Contributor

Merged to master in 56d50af

anatoly-os added a commit that referenced this pull request Aug 26, 2020
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

Successfully merging this pull request may close these issues.

None yet

3 participants