Split screen focus a little confusing

This is a minor point really, but I thought I would mention it anyway.

When you split the screen, the focus can be a little unclear; the top window is highlighted, but when I select another document, it appears in the bottom window, which incidentally, is where the cursor appears to be.

Sorry, I’m not sure what you mean… By “window”, I assume you mean “pane”? And by “highlighted”, do you mean the underline? The pane with the current focus has its title underlined in the header view.

The title with the underline should always be the one whose pane has the cursor/keyboard focus. I can produce a case where this does not happen, but if you can, could you please provide me with steps to reproduce it? It should, in fact, never happen, given that the underline is set for the editor set as “current”, which is also the one affected by selections…

Thanks!
Keith

Yep, I do mean ‘pane’ and ‘highlighted’; sorry about that … :slight_smile:

Yes, what seems to be happening is that the top pane is showing the highlight and the lower pane is where the actual cursor is. So the focus is the bottom window.

I can get it to happen intermittently (once every ten tries or so), but I’ve not been able to spot a pattern to it. I’ll try to work on it a bit more when I get home this evening. So far, it only seems to happen when I’m splitting a sub-document. Mmmm …

I need to look at it a bit more.

It isn’t too much of a problem though, since I know that the focus is always on the bottom pane, no matter where the highlight is …

The new inspector pane is a vast improvement by the way; not that there was really anything wrong with the old one …

Thanks - this definitely sounds like a bug. If you could isolate it and provide me with the steps necessary to repeat it, I would be very grateful, as I have not yet been able to get this to happen myself.
Thanks!
Keith

Got it.

1/. Open document
2/. Split screen (focus is on the bottom pane)
3/. Click on top pane (focus is now on top pane)
4/. Now close the top pane (note how there is no highlight on for the single pane)
5/. Split screen (focus is on bottom pane, top pane highlighted)

Okay, to summarise.

If you close the top pane when it has the focus, then the highlighting fails to work correctly until you restart Scrivener. Seems to be repeatable 100% of the time.

Hope that helps … :slight_smile:

Cool - thanks. This was an easy one to fix. There were a couple of places in code where I just wasn’t updating where the underline should be - fixed for beta 6.
Thanks for tracking this one down,
Best,
Keith

No problem, and while you’re feeling grateful, I would like to request a way to close either pane in a future version … :smiley:

But in the meantime, go to sleep man! It’s nearly midnight!

p.s.

The chapter numbering reset? genius!

I followed the recent discussion on that, and I toyed with the idea, but in the end decided that I disagree with it (or rather, I think it’s a good idea in itself, but not in the current set up - so yeah, more of a “future” possibility than something that will appear soon). The current set up makes it pretty clear which pane will be closed (that is, it has a close button in it). The bottom or left pane always has priority, and you can always choose “Swap documents” from Layout in the view menu before you close the pane if you want…

Best,
Keith

Ah.

I didn’t know about the swap documents. That’ll do the trick.

Is there a clever MacOSX way of assigning a keystroke to it?

S’okay. I found it!

Count me as another voice in favor of closing either pane. I would’ve really liked this feature when I began using Scrivener, but my work habits have slowly morphed until they now fit Scrivener quite well.

Nonetheless, I can still see the usefulness of closing either pane. I always work in the midst of two histories of documents, flipping forwards and backwards in each pane. Simply swapping the documents doesn’t preserve the carefully constructed history of the pane. Incidentally, it’d be handy to be able to edit the histories for each pane in order to add/remove items from the middle. (I won’t hold my breath for this one. :slight_smile: )

–rob

But what are the advantages of the current setup? I’d like to add my hoarse bariton voice to the choir of people who requested an easier way to close documents in split-view. In my opinion the current design is just not as elegant and user-friendly as the other features and interface details of Scrivener.

I think that there are two problems with it. The first problem is that the “Close” button in the title bar of the primary document and the “Toggle split view” button in the title bar of the secondary document both do the same thing: they close the primary document. These buttons look differently, and they belong to different documents, but they have the same effect. This is rather confusing.

The other problem is that the current setup gives priority to the secondary document, not the primary document. In my workflow, secondary documents are usually just images or notes that I want to view alongside the chapter I’m working on, and I would like to be able to quickly close these files when they are no longer needed. Instead, I first have to “swap” them with my primary document so that I can access the close button in the upper/left title bar. But why do I have to do that? It’s just an awkward, time-consuming workaround for what could, or should, be as simple as clicking a button. If both title bars had a close button (as has been suggested by other users), one could toggle the split view and simultaneously decide which document / document view is closed. If I knew why you decided to disagree with this idea, it might be easier for me to live with the current design …

Good points; all of them.

But with two close buttons, you would not be able to change the orientation of the split, which you can do with the current layout.

What are you meaning by this? For me it is consistent. If I make a split, the primary document is always on the bottom or on the left. This seems intuitive to me. With the horizontal split, the layout of the application matches the typical 3-pane layout, where your primary content is in the lower area of the application. With vertical, why would you want the primary document at the point furthest from the Binder? Given that these are consistent – the top split is always the one that will close, as is the right split, why try to force the application to work in an opposite fashion?

Here is a counter-argument. This is all talk of buttons. I rarely ever use buttons. If there are going to be two buttons, giving the user the choice to close either side; which side should the keyboard shortcut destroy? Even though the buttons are a separate issue from shortcuts, if you change the buttons you create a usage rift between the two. Either that or you would need four different keystrokes. One to close the left, another to close the right; one to split vertically, another to split horizontally. There would be no drop-dead simple way to just close the split without thinking about it. You would have to decide which keystroke to use.

What about the menus? Would there be a glut of menu items related to primary/secondary – and how would the menus communicate what that is? Would they have to constantly relabel themselves depending on split style (Close Left/Close Right; Close Top/Close Bottom). That’s just a mess; but a simple “No Split,” would no longer have any meaning.

Rayz brought up a good point, too. Adding this ability removes the ability to swap split styles on the fly – at least intuitively. Option clicking on an icon that represents a window state to do an optional window state is one thing, but what does an optional state of a delete icon mean? It isn’t semantic to turn close buttons into style switch buttons.

Basically, you are proposing a dramatic increase in complexity and reduction in functionality for the rest of the application, for the benefit of only one area that – once you get used to it and work on the right side of things – is 100% predictable and effortless as it is.

Thanks for the detailed reply, Amber - that pretty much sums up my feelings, too. I won’t go into the technical reasons, which are a bigger barrier on my end.

This is really getting picky now, which I take as a good sign that Scrivener is ready for 1.0. :slight_smile:

I’m afraid on this point, it doesn’t matter how many voices are added to the chorus - baritone or not - this will not change for the foreseeable future. I already said this in an earlier post - it’s not something I’m ruling out, as it is a decent enough suggestion, but I am ruling it out for the next few versions, as I cannot afford to spend the amount of time on this that it would require - it would actually take more rewiring than you think, as the bottom or left document is hardwired as the main document.

Best,
Keith

Well, I’ve been a lurker on this one. But I think this sounds quite reasonable. I too think it a good idea, and I can see it is on your radar as a ‘maybe’ at some point. It will be a good thing to add if/when it happens. Until then, we’ll live!!! :slight_smile:

That’s an interesting point, because it helped me realize that it is not the split view setup as a whole but one particular detail that seems wrong to me. I never had a problem with vertical split views. The primary document is on the left, where it should be, and the secondary document is on the right and can be dismissed with the close button. It works exactly as expected. When hierarchical relationships are presented horizontally, they usually descend from left to right. This is why it “feels” logical that the primary document is on the left side of the editor window (and why it makes sense that the Scrivener interface has the Binder on the left, the editor in the middle and the inspector on the right).

When hierarchies are presented vertically, they usually descend from top to bottom. Think of any org chart or outline. Scrivener’s Binder follows the same principle: Draft folder on the top, Research folder in the middle, Trash on the bottom. But there is one detail where Scrivener deviates from this principle: In vertical split view, the primary document is on the bottom of the editor pane, not on the top. This is what I actually meant when I wrote that Scrivener gives priority to the secondary document. I never realized that the current setup assumes that the bottom pane is the right place for the primary document.

In horizontal split view, I always have my primary document in the upper pane and pictures or notes in the lower pane. This is the most intuitive layout in my opinion, but it is not supported by Scrivener. Since the lower pane has priority, Scrivener forces me to “swap” these secondary files with my primary document to access the close button. Hence my frustration with Scrivener’s split view design, and my feeling that the program works against me rather than for me.

Not true. If we take Mail as a typical three-pane app, the primary content - a list of all your emails - is in the upper pane, and the secondary content - the content of one of your emails - is in the lower pane. Hierarchically, the content of one email is inferior to a list of all emails, and that’s why it is placed on the bottom. Mail and other three-pane apps like Mori or DevonThink follow this principle, but Scrivener’s horizontal split view does not. If the primary document was in the upper editor pane, it would match the typical three-pane layout.

This thread has brought up many good arguments in favor of the current setup. My problems with its behavior can be narrowed down to one particular aspect: the position of the primary document in horizontal split view. You did not rule out the possibility that there might be changes in the future, and that’s great. So, thanks to all for a very constructive discussion :slight_smile:

Sadly (for you), I tend to work with the document on the bottom and the reference material above it… It just feels more natural for my eyes to refer to the top of the screen while typing on the bottom. :slight_smile:

This is an interesting case in point for something I’ve been pondering about Scrivener in general. Viscerally and habitually, I agree with Jan that having a primary document on the bottom seems weird. But once I start reading Keith and AmberV’s explanations I get an inkling that I’m just stuck in old habits and paradigms that may not be serving me as well as I thought.
Sometimes a forced shift is a good thing.
(of course that hasn’t stopped me from assigning an Fkey to “Swap Documents”!)

Trying to adjust,

E

That is interesting, Jan. Thanks for sharing how it is confusing to you. I suppose I’ve always considered the content of the email more important than the list all of all the emails in the currently selected bucket. Having worked in so many 3-pane style applications, I am just accustomed to having the most focussed bit of information in the bottom of the application, with a grand list on the left and a supporting list on the top. Scrivener kind of goes against the grain by allowing anything in the top position. You could have an Outliner list with the link button on and it would act exactly like Mail does (in general), but you can also put another document up there unlike any other 3-pane application. But for me, the damage is already done, I’m used to the focus being on the bottom half of the screen. So I guess it is just a psychological difference between us. You have always put more importance on the intermediate list, so you expect the most important data to be in the top half of the screen.

But all of that aside, I do agree with you on one point. The concept of having a primary and secondary side of the split which closes consistently is probably the least intuitive part of Scrivener (empty Corkboard syndrome, before that was solved, was right up there). I know when I first started using it, I expected the side which had last been used to be the one retained. It caused quite a bit of confusion until I realised it was always one side that was going, no matter what. Now that I know the code, and I’m used to it, the process is second nature and I rather like the consistency, but it definitely was not intuitive.