Lock In Place in 3.2.1

Just updated my secondary machine to 3.2.1, which is running MacOS 10.13.6. (I’m holding off updating my main machine, running 10.15.7, until the probs around 3.2 are cleared.)

Now when I set a window to Lock In Place, in the horizontal title or document bar at the top I’m getting a barely discernible change from one shade of grey to another very slightly darker grey.

I use Lock In Place a lot, and the old pinkish colour in the bar was an easy-to-see and useful visual guide to Lock In Place.

Now, with the new two-shades-of-grey, it’s very hard to tell if it’s locked or not. In my view, this is a change for the worse. I can’t see any setting that might revert to the previous performance.

I posted about this originally in “3.2 issues” in the Bug Hunt forum in response to it being raised by auxbuss, among other points, but I figured this part of the forum might be a better place to deal with it individually. (Auxbuss was referring to this problem in dark mode, by the way, which I do not use.) There was a comment there that making a change to the “system accent” colour might help (I presume this meant the Appearance colour for buttons etc set in Prefs/General) but my setting there remains at blue, so that doesn’t seem to be the culprit.

My preference would be to revert to the old way, with a distinctive colour in the top bar when a doc is set in Lock in Place mode, which for my purposes has always worked well.

Hi there o/
I added some extra visuals to demonstrate the problem on the thread you mention:
Hopefully someone at L&L will respond once the work-week kicks in.

OK auxbuss, looking forward to an L&L response some time.

I thought I posted this in Technical Support, but it seems to have been moved. Will it get an answer here?

Yes, I moved this to feedback, since it seems to me it is primarily feedback on the change.

Sorry, I wasn’t very clear on that point: this setting impacts the active split colour. If you don’t have splits open then you won’t be seeing any change when messing with those settings.

The fact that the active split can be almost any colour of the rainbow now is what drove the change to make the locked state a grey shift (which yes, doesn’t work well with the Grey accent, but this was considered an acceptable sacrifice), so as to avoid having two red splits when one means locked and the other means active. There is another cue by the way, but you have to know where to look: note the padlock icon that appears on the right-hand side of the header bar.

I don’t actually disagree with you, to be honest. It’s already confused me a few times as well. :laughing:

On one machine I have grey accent, but on another blue. The problem is the same on the machine with the blue accent.

Activating Lock in Place reverses the visual cue of the active document when using dual editors, which I do 100% of the time.

When I’m editing, which is most of the time, I need the visual cue, as the text may well be almost indistinguishable visually.

I’m genuinely astonished at this change. Why was it necessary? It worked before, and I don’t recall any complaints about it.

AmberV, thanks for replying.

Your explanation implies that a change to the way split-windows highlights work in 3.2 means the “grey or grey” Lock In Place highlight is now much less visible and almost useless as a visual cue.

I think this needs attention to restore the clearly visible distinction with colour when a window has Lock In Place active. (And I never knew the tiny padlock was there until you mentioned it—which speaks for itself, I think.)

I wonder if this is something we’re stuck with in 3.2.x or if it’s likely to be fixed. If not, it would make me hesitate to update my main machine. Anyone at L&L know?

I’ve had to stop using Lock in Place, because as soon as I switch it on, the wrong editor is highlighted.

I wish understood the thinking behind this. From what I see the active editor is highlighted – as it has been forever – unless Lock in Place is active, when the inactive editor is highlighted. Verily the thinking at Scrivener HQ is a curious thing…

I kind of understand the thinking behind this change: the active editor should be designated by the user requested system accent colour. Okay. Fine. Not just a red (or was it blue?) line any more, the active editor is indicated by a line in whatever colour the user likes. (I waffle between purple and green myself.) But as a substitute for the distinctive pink lock bar, the change in grey shade plus the tiny lock symbol just doesn’t cut it as a visual cue. If anything, the grey level change confuses folks.

There are a few ways that L&L might handle this:

  1. Leave it as it is. People will learn to look for the coloured line and the tiny lock symbol. There will be much grousing, but few are likely to actually switch away from Scrivener because of this. The change in grey shade in the header bar will continue to be confusing and users will learn to ignore it.
  2. Revert to the old way of showing active editor split plus locked editor. This method is cheap in developer time and has the advantage of keeping the existing user base happy.
  3. Make the background of the locked split a tint (or shade, in the case of Dark Mode) of the system accent colour. This continues the older way of displaying locked status, but freshens it by using the system accent colour.
  4. Make the lock icon a lot more noticeable. Bigger, in the system accent colour, with or without a contrasting outline, add a caption… there’s a lot of possibilities here.

My own preference is for anything save Option 1. :smiley:

I agree with all of the posters above.

Silverdragon is right that it’s fine to have the currently active editor highlighted, but a locked-in-place editor needs something more conspicuous than a darker shade of grey and a tiny padlock. Almost anything would be an improvement on how this works since version 3.2.

(I’ve just checked and I see that I haven’t posted here since 2013, although I use Scrivener all the time. It just works the way it should. Or rather, it did, and now it doesn’t anymore… )

Silverdragon, I definitely vote for your option 2. Bring back the pink lock bar!

Sadly, it appears that L&L are sticking by this incomprehensible design decision. Such a shame.

Do you mean 3.2.2 doesn’t deal with the problem?

That’s right. Option 1 is still in place.

I do.

I wish someone from L&L would explain the rationale behind it.

That’s funny, I thought KB already had.

Disappointing. Scriv persons, might we have something good on this in 3.2.3?

No, this won’t be changing. The previous system of blue for focussed and pink for locked was never entirely satisfactory because you’d end up with a blue piece of UI when everything else conformed to the system tint colour. We now abide better by standard UI conventions of using the system tint colour to indicate focus. That meant that lock in place had to change, though, since if you had a red system tint colour it would be difficult to tell apart focussed and locked. So locked is now a dark grey.

Note that there is a very distinctive visual clue of an editor being locked in place even without the colour, though: a lock icon appears in the editor bar. So it’s still easy to tell at a glance that an editor is locked, even though it might not be as in-your-face as the pink of yore.

Thanks, Keith.

This completely misses the point of the complaint. The problem is not identifying which editor is locked, but which editor is active; though both were far, far easier to discern in previous versions – hence the absence of complaints!

This is an absolutely terrible decision from a usability and design perspective, imo. But hey ho, I can live without Lock in Place. It’s a shame to lose it, but I can more quickly adjust to that than having the wrong editor window being highlighted as active.