Here are some interface bugs and shortcomings. I didn’t have time to read all the bug reports, but I think most of the problems have not been reported yet.
Bugs:
[list]- When you browse files using the arrow buttons in the header, the Binder doesn’t highlight the document that’s currently active. This is very confusing. See HBN/Mori for the correct behaviour.
The Editor scrollbar is not always proportional to the text length. For example, open Step 17 of your tutorial and look at the editor scrollbar. Now switch to the final “note to beta testersâ€
Nope, sorry, the current behaviour is the “correct” behaviour. And in fact, I just opened up Mori and it behaves exactly the same way. The navigation buttons should have no control over the binder selection; they have no right. I implemented this in SG as a user suggestion, and I was never very happy with it. The standard behaviour for this in apps that have nav buttons is that these buttons have no control over the outline view - see Xcode, Mori etc. The navigation buttons hold a history for the particular document, nothing more. If you need to find where that document is in the binder, use “Reveal in binder” (available in the menu when you click on the icon in the header). This behaviour will not change.
[quote]
The Editor scrollbar is not always proportional to the text length. For example, open Step 17 of your tutorial and look at the editor scrollbar. Now switch to the final “note to beta testersâ€
I think Jan is referring to the Tutorial, Step 8: splits, which gives similar information in two different paragraphs:
"Now let’s take a look at some of the other organisational tools of Scrivener. For a start, the chances are that from time to time you are going to want to split your document. So let’s do that now. Go to View > Layout > Split Horizontally. Suddenly, this document is displayed in two panes. Note that through the Layout menu, you can also choose a vertical split, to get rid of the split altogether, or to hide the header and footer views for the current document view.
All well and good, but we don’t want to be limited to viewing only one document at a time, do we? And naturally, we’re not. Go to View > Layout > Split Horizontally in the menu. (Notice that there is also the option to split vertically, to remove the split, and to hide the header and footer views for the current document view.) The document view will now be split into two panes so that you can view different parts of the same document. Hardly revolutionary, but always useful. The next bit is even more useful, though:…"
Hmm. You’re right. In HBN (which I still use more often than Mori), the history button does control the selection in outline view. I assumed that Jesse didn’t change this behaviour.
That’s a very logical explanation for what I thought was wildly illogical behaviour, but I’m used to that from arguing with my gf I still don’t find it entirely convincing. It’s true that the navigation buttons only control the history of the files, but since they also control which document is being displayed in the Editor, you often run into the very confusing situation that the document you’re editing is different from the one selected in the Binder. But I do understand the reason behind this design, and it’s certainly not a deal-breaker.
Yes, I have the text scaled to 150%. I thought that the scroll bar should always be proportional to the text, resized or not. If this problem is unavoidable, ignore it. It’s not that important, really.
Great, thanks.
That’s what I meant. Looking forward to beta 2.
Obviously, my English writing skills are much worse than my reading skills. Entschuldigung
There are a few reasons I prefer the current behaviour. The fact that the selection is different in the binder can be an advantage. For instance, often if I’m editing a document, I suddenly realise I made a change that also affects a document I had open a while back. So I can navigate back until I find that document. Then, instead of navigating back forward again, I can just click on the selected document in the binder to get back to where I was originally. In Xcode I use this without even thinking these days; it can be a real time-saver.
Unfortunately it seems that it is. Scroll bars in general can be a bit eratic in Cocoa. I spent ages trying to find a solution, but no one on the Cocoa lists or forums could help me. Ultimately, I noticed that both DevonThink and Avenir display exactly the same weird scrollbar behaviour when the text is scaled, and concluded that if the talented and experienced programmers over at Devon Technologies can’t fix this then I have fat chance. Ultimately, like I say, it’s caused because you have to scale the whole view, not just the text, which means that the empty space gets made bigger, too.
And a darn good one!