Lock editing for Palettes globally in upcoming MS 3.3
If you drag an object (ornament, clef, etc.) from the palettes towards the score, you have to be quite fast so that the palette does not switch to edit mode and everything shifts when you drag it away.
This is irritating every time and will cause some inexperienced or slow mouse users to unintentionally modify a palette. You can make every single palette not editable, but there is a lot to do with about 24 palettes - so this is really uncomfortable.
The easiest way would be to be able to lock the palettes globally so that no unintentional editing takes place. Otherwise, this is of course a cool game of skill and certainly also trains the eye-hand coordination 😋
Comments
Selecting the target element and using double-click is the much better method and not prone to the problem you describe.
But yes, I guess it should be made harder to inadvertently modify the palettes
In reply to Selecting the target element… by Jojo-Schmitz
That's true, of course. I'll do it one way or the other, if I use the mouse at all. Otherwise, keyboard shortcuts are certainly the most effective (if there are any for the object you want to use). But the average user will also use drag and drop, I suppose.
In reply to That's true, of course. I'll… by enkidu
But the average user will also use drag and drop, I suppose.
...and more intuitive for a beginner.
I would like the option to globally lock all of the palettes so you can the unlock a palette only when you want to edit it, but you do have the option to lock each palette and they remember they were locked which is a big improvement over past implementations. It is slow, but thankfully it's a one time chore.
There are certain things that seem more intuitive to drag to the score like key and time signatures that are applied to measures. Other things, like articulations, I always apply with a double click and rarely accidentally move them, though this does happen when my hand gets unsteady. I realize everything can be applied both ways, but it's not what I normally do.
Are you using the current RC? There was a delay added so the editing doesn't happen unless you pause half a second or so. But even if you do pause, it's not harmful - sure it's a visual distraction for the cell to clear, but unless you abandon the operation, nothing actually changes.
That said, I'd also favor an option to lock all palettes at once.
In reply to Are you using the current RC… by Marc Sabatella
Just the other day, I started to drag something to the score and paused to decide if it was what I wanted. It was in 3.3-RC3 while viewing the advanced workspace (which I didn't turn off edit) and I now have an Edited Advanced workspace for no reason.
In reply to Just the other day, I… by mike320
Yep, it can happen, I agree, which is why I do support the option to disable editing globally. I'm fine with the default being to have it enabled, as the goal is to encourage experimentation and customization, but once one has things as one wants them, it would be nice to protect oneself against accidental changes.
BTW, one of the late changes that resulted in RC3 had to do with workspace management, the "View / Workspaces / Reset workspace" should now provide a quick return to the unedited state. So if you really don't intend to ever edit your workspace, it's easy enough to undo all changes. My own concern has more to do with custom workspaces that one has invested some effort into already, as "reset" will actually return these back to their initial state (e.g., a copy of basic or advanced). I suppose I could get in the habit of cloning my own custom workspace to have a safety copy.
In reply to Yep, it can happen, I agree,… by Marc Sabatella
I thought I remembered there was a way to reset it, I didn't remember how though. For custom workspaces, fixing an accidental edit doesn't create a new workspace. Undo would be nice but I can live with how it works now. As I said, locking all of the palettes is a one time exercise, you just have to remember to return it to not editable after you intentionally edit it. I'll get used to doing that after I accidentally edit it a few times.
In reply to I thought I remembered there… by mike320
Why I started the topic at all is the fact that inexperienced computer users (not me 😉) should be prevented from making changes too easily by accident. Often these users are also not able to fix it themselves, whether there is a reset option or not. I think we all know this type of user. Parents are at the top of this list and it was of course always the computer itself that changed something by magic.
The second reason is that in my personal opinion a toolbar should be changeable, but not at the same time with normal use (i.e. when writing music).
If you move over the palettes a little slower (maybe you are still planing, or you are just moving your mouse slowly), the neighboring objects will start to slide around. But somehow you don't want to have to watch out to "destroy" your tools when you're trimming your masterpiece. This makes the menu bar not very robust, but somewhat vulnerable, if you understand what I mean.
In reply to Why I started the topic at… by enkidu
I agree.
I also believe that the basic and the advanced workspace should be locked by default, while user-palettes should be editable by default.
In reply to I agree. I also believe that… by ecstrema
Agreed.
In reply to Why I started the topic at… by enkidu
One of the main points of the redesign was to make it easier to discover how to customize workspaces - to make this something even beginners would be comfortable doing. Raising the barrier to entry by making people discover how to unlock the workspace is a step right back towards where we were, so to me that's unwise and highly unlikely. Plus, there is a nice "Reset" command in the menu, so it's very easy to undo accidental changes to the default workspaces. But making it easier to lock them for users who so choose is, to me, still a good idea. The ability to do it palette-by-palette, but it would be nice if there were a global toggle.
Lengthening the delay it takes to initiate a palette customization (right now it's around half a second) seems reasonable though, to reduce the likelihood of accidental rearrangement while still keeping the action discoverable.
In reply to One of the main points of… by Marc Sabatella
I agree with the general sentiment that being able to accidentally edit a workspace during normal use is bad. It seems that not all of Tantacrul's ideas are so good or the implementation could have been better.
In reply to I agree with the general… by mike320
Well, what I'd say is "good" is in the eye of the beholder. Different people work differently, so what's good for one might not be good for another. This change is good for some, not as good for others.
One thing that would help is if we added a "tour" that kicks in the first time you actually do edit a palette, telling you what happened and how to reset. Won't be of much use to long-time users who have probably turned the tours off, but should help new users. In general, the tours could use an update as much has changed since 3.0.
In reply to One of the main points of… by Marc Sabatella
Then, however, I would suggest an additional assistant like Clippy (MS Office), which accompanies you on the adventures of customization 😋
I didn't know that the goal was to make customizing menus more accessible. My experience tells me that it is better for certain users not to be able to change anything too easily. Of course, you have to find a balance between too easy and too difficult. Personally, I don't like it so much when the palette elements suddenly move, so it would be nice if we could at least lock it globally. Standard locking would make sense at least for the basic pallet.
Instead of the delay you could have used Shift or another key as modifier key to move elements. Of course the hurdle for customization would be a bit higher.
In reply to Then, however, I would… by enkidu
The tours I mentioned are the additional Clippy-like assistant. Presumably you turned them off long ago, but they are on by default for new users.
If you check out the video in the official release announcement, or the description in original beta announcement, you'll learn more about the goals, but yes, the idea is that users should be able to easily create an environment tailored to their needs - this shouldn't be limited to a tiny handful of power users.
In reply to One of the main points of… by Marc Sabatella
> Raising the barrier to entry by making people discover how to unlock the workspace is a step right back towards where we were
Agreed. But maybe there's is an elegant and easy way that allows for both. Maybe keep workspaces "unlocked" by default?
In reply to > Raising the barrier to… by RobFog
That's what I suggested indeed. Unlocked by default, an easy way to lock/unlock a workspace as a whole, and a tour that pops up for new users the first time they successfully (accidentally or otherwise) edit a palette informing them of the reset and other workspace controls.
In reply to > Raising the barrier to… by RobFog
For discoverability, lock the workspaces by default. If the user attempts to drag an item to a palette that's locked, create a popup telling the user they need to unlock the palette.
In reply to For discoverability, lock… by mike320
@mike320: I wouldn't find that bad. This gives less experienced users the necessary information on how to modify palettes without accidentally editing them, as they are locked by default.
In reply to For discoverability, lock… by mike320
@mike320 Good idea. Perhaps even: "If the user attempts to drag an item to a palette that's locked, create a popup asking the user whether they want to create a new custom workspace"?
In reply to @mike320 Good idea. Perhaps… by RobFog
The new workspace isn't necessary to modify an existing workspace any longer. Since they still exist perhaps this isn't a bad idea.