in Note Groups UI make palette selectable, then click notes to toggle between selected beam property and auto

Can you describe what you have in mind in more detail? What I like about the current method is that you *don't* have to use drap and drop for the most common case - breaking or joining simple beams. A single click does the trick. Only the sub-beam options require drag and drop. If we made it so you first click the note then double click the icon, that actually makes the most common case harder. Probably there is a way to get the best of both worlds, but it isn't clear to me exactly how. Something like single click the note to merely select it, double click to do what single click does not wouldn't be a big step backwards in actual effort, but it is a bigger step backwards in discoverability.

Indeed. But I would still like to see discussion of the issue I raised: changing the behavior to allow single click of note followed by double click of icon (making it work the same as the regular palettes) actually *doubles* the amount of work required in the usual case; it only helps with the sub-beam case. So I'd like to see a concrete proposal for a system that helps the sub-beam case *without* compromising the usual case.

I personally would not want to change the current default behavior of just single clicking doing the trick.

The way I advocate for this is to have the the first beam property (Beam Start) be selected in the palette initially when the UI is first opened. And I would have the behavior such that clicking on a note would toggle between the current selected beam property and Auto. Which would mean get the same behavior if left the first beam property (Beam Start) selected.

I want to note that NoteGroups::noteClicked() currently starts with:

      if (chord->beamMode() == Beam::Mode::AUTO)
            chord->setBeamMode(Beam::Mode::BEGIN);
      else if (chord->beamMode() == Beam::Mode::BEGIN)
            chord->setBeamMode(Beam::Mode::AUTO);

That is from Werner's commit 4 years ago. I have a slight issue with this: I think that the the else condition should just be a regular else, not an else if, such that if clicked on a note with any one of the other beam modes (BEGIN_32 or BEGIN_64), then that beam would revert to AUTO.

Anyway, the pseudocode for how I think this feature would work in this function is:

      if (chord->beamMode() != selectedBeamMode)
            chord->setBeamMode(selectedBeamMode);
      else
            chord->setBeamMode(Beam::Mode::AUTO);

I also should note that I don't think palette class currently doesn't have the ability to hold a selected state.

mike320, the pseudocode I proposed in #5 is doing what you are requesting in #6.

I also discovered that palette cells can be "selectable" by calling palette->setSelectable(true).

I'm going to go ahead with my proposal.

This title reflects how I'm implementing this feature.

I've implemented and am ready for code review: https://github.com/musescore/MuseScore/pull/3012/

I tried it and it works as advertised. I'm not sure I like it.

First, dragging doesn't work at all anymore but we can still drag from the palette
Then, the previous behavior of toggling is kept but only with the first item selected.

I don't know what you mean by "dragging doesn't work anymore" because I remember making sure dragging still works. The only difference I caused with dragging is that whatever was last dragged becomes the new selection, that behavior I unintentionally introduced.

Also I don't understand your second sentence.

I had to rebase the code...there was some divergence that might have caused it to not behave properly, and there was also a typographical error in my code where I had one of the beam properties swtich case confusing AUTO with MID. And to be honest, I'm also a little bit bothered myself by how "AUTO" means something slightly different inside noteGroups.cpp than it does in the main score. It seem inside noteGroups.cpp it will mean that the beams are connected left and right (like MID), but in the main score it means to use whatever the time sig says. Which is a bit confusing because if in note_groups.ui the user is defining what AUTO is for each note...

I'm going to make a few more enhancements before I repush the PR:

1. I don't think "AUTO" makes any sense inside the noteGroups.cpp...it seems that auto is basically "MID" in that file. What I'm going to do is not have AUTO anywhere inside noteGroups.cpp, and have the default newly constructed time sigs be called MID instead where it is currently "AUTO". There isn't a AUTO beam property in note_groups.ui palette anyway. So that means the default toggling behavior would switch between the current state and START. I hope I'm not totally confused.
2. I think that there need to be a tooltip that displays the state of the beam property for the nothead that you are hovering over. This is important because it is somehow not possible to know what the beam property of a note is just by looking at it's beams, because the beaming also depends on its neighbors
3. I'm thinking about modifying palette code so that if drag a cell then won't change the selector to that cell...this is to prevent that Beam Property mini palette in the note_groups.ui from changing its selected index when the user is simply dragging & dropping.
4. Oh, and I'm regretting putting the horizontal spacer between the reset button and the BeamProperties palette group box. I'm going to instead put the spacer to the right of the beam Properties palette group box. That way the beam properties palette doesn't move too far right (and away from most of the notes) when moving the right hand side of the window.
5. I also think the "1/8", "1/16", "1/32" aren't actually useful because user's brain can already figure out what each score view represents. All it does it is take away valuable realestate needed for displaying the very wide 32nds. Maybe I'm being a little too nitpicky with that, though...

ok, I discovered the same thing...ended up removing them after I put them in, thanks for the input.

What I have done is increased the area whereby is able to click the notes (#175011: Note Groups UI increase Mouse Click region size for each note)...that is helping the usability, although trying to find the sweet spot.

Update: To keep the previous behavior the same, I'm not starting out with any palette cells selected initially. When click on a note without any cell selected, I've left the original if statement for that case, so behavior is identical to previous.

I repushed with following behavior:

1. Increased the clickable region such that click event will change beam mode of nearest note (so can click on whitespace).
2. If a palette cell is selected, then click on notes will change to the selected beam property.
3. If no palette cell is selected, then keeps prior behavior whereby clicking notes toggles between palette's currently selected beam mode and mid.
4. Reset button will now remove the palette's selection.
5. Removed the unnecessary labels "1/8", "1/16", "1/32" from the UI.
6. Moved the hspacer on the UI to be to the right of the palette.

I'd like 2.1, but lasconic makes those calls.

This issue's PR has yet to be accepted. I think lasconic had disagreements with feature (read the PR comments on github).

The two huge improvements you mentioned were different story issue PRs which were accepted.

If you want to test my PR you will have to compile it.

The pull request got archived. Also I am not sure whether this suggestion is actual with the recent single-click palette changes, although it still might be applicable.

As far as I can tell, drag & drop is still required to apply the "sub-beam" options (ordinary join & break work fine with just a click on the note groups). So sub-beam is not keyboard-accessible at all right now, it seems. Worth addressing for sure, although probably not the highest priority such issue.