Add shortcuts to scroll the Viewer up and down

[tmarplatt]

The problem

Currently if a user has an open document in the viewer that spans more than its full height, and they need to scroll back/forward, they're forced to use the mouse to shift the viewer to the desired section of the document.

When using novelWriter mainly with the keyboard, this is distracting and flow-interrupting. There are already a set of shortcuts that improve keyboard only usage, but here it is lacking.

The solution

Implement these new shortcuts:

• Viewer page up: scrolls the viewer one full height up.
• Viewer page down: scrolls the viewer one full height down.

Both shortcuts should be able to work regardless of which panel has focus. You should be able to scroll the Viewer from the Editor or the Project or Novel trees.

If we're traversing viewer history, do not reset it, instead update the viewer scroll position for the current history element, if possible.

[vkbo]

Funny enough, I was just about to add a feature ticket for this. I recently discovered that my code editor has keyboard shortcuts for scrolling, and thought this might be handy in the novelWriter editor too. It makes sense to have a separate set of keys for the viewer, so that they scroll independently.

Editor

• Here I'd like to add Ctrl+Up and Ctrl+Down to scroll up and down in small increments when writing.
• The PgUp and PgDown keys already scroll whole pages up and down, so that is covered.

Viewer

• I'd also like to let the Ctrl+Up and Ctrl+Down keys work here too when the viewer has focus.
• The PgUp and PgDown keys already scroll here too when the viewer has focus, but I propose adding Ctrl+PgUp and Ctrl+PgDown to scroll the viewer from anywhere in the GUI.

Project Tree

Ctrl+Up and Ctrl+Down currently moves items up and down in the project tree. It would be unfortunate with different behaviour in these widgets on this, so I propose:

• Add a new mode key combo triggered with say Ctrl+M that switches the tree into edit mode and lets you move items in various ways with keys. This has already been requested (see for instance Keyboard shortcut to Move Tree Item to different folder #674), but with no good solution for key combos to cover all bases without the risk of introducing shortcuts that are easy to press by mistake. Having them as a separate mode, with a GUI indicator, may be a good approach.
• This will free up Ctrl+Up and Ctrl+Down to work in the same way in the Project Tree as in the other widgets. In fact, I can capture them globally and apply them to any scrollable widget with focus. Both horizontally and vertically.

[tmarplatt]

I would welcome more specific abilities for doing heavylifting of documents and folders. E.g.

• Expand/Contract all items inside this item (helpful for large projects/complex trees)
• Move this item up one level
• Move this item into to the (same level) item above (helpful after creating new items meant for a different context)
• Duplicate this item and all subitems
• keep track of all tree changes in the undo history

Together with a toolbar only visible in a "project tree editing mode" that displays all of its functionality to the user. The user should be able to perform all of project tree edits using the mouse.

This may sound contradictory to what I said above, but you have to consider that editing the project tree is something, while very involved and a reflection of the written work's core structure, also a rather infrequent task. A user will not change the project tree with such a habit that they will learn the shortcuts to heart. Too much time may pass before they feel the need to rearrange their tree. The user will normally do most of it using the mouse.

[vkbo]

• Expand/Contract all items inside this item (helpful for large projects/complex trees)

This already exists on all levels. See #1122, added in #1129.

• Move this item up one level
• Move this item into to the (same level) item above (helpful after creating new items meant for a different context)

With the mouse or with keys? The latter is the topic of #674 that I mentioned. As the thread discusses, there is some ambiguity in a keyboard implementation.

• Duplicate this item and all subitems

This is discussed in #1123, but I agree that at least copying single items would be useful. Perhaps a simple implementation of cut, copy and paste would do, with a ctrl + drag copy option for mouse. It's pretty standard.

• keep track of all tree changes in the undo history

Creating undo/redo stacks is a tricky thing to do, and I've considered this, but the main problem with this is that if you delete an item permanently, the undo stack will stop when it reaches that item as it cannot get past that step in the undo history. Having such a history in a tree structure is fundamentally different than in an editor where there are no truly destructive actions.

I assume this is also why for instance the Nautilus file manager only lets you revert last action.

Together with a toolbar only visible in a "project tree editing mode" that displays all of its functionality to the user. The user should be able to perform all of project tree edits using the mouse.

I think it makes more sense to do this via context menu in combination with drag and drop, but let's see.

This may sound contradictory to what I said above, but you have to consider that editing the project tree is something, while very involved and a reflection of the written work's core structure, also a rather infrequent task. A user will not change the project tree with such a habit that they will learn the shortcuts to heart. Too much time may pass before they feel the need to rearrange their tree. The user will normally do most of it using the mouse.

I agree in part, but there are users who want to change the tree with shortcuts. I do need to make some change if the Ctrl+Up and Ctrl+Down keys become scroll combos, otherwise people are going to make mistakes in their project tree a lot.

[tmarplatt]

• Expand/Contract all items inside this item (helpful for large projects/complex trees)

This already exists on all levels. See #1122, added in #1129.

This one doesn't do exactly what I mean. Currently when you Expand all, it does in fact expand all the way down the tree. I do mean "inside this item" as "just for the level below the current one", and do not traverse further. Likewise for Contract all: when you expand again, all sub items are back in their contracted state (I would like them to remain in an "expanded child within a contracted parent" state, that is restored once you expand the parent back).

Why would the user want this complex behaviour? Users are fickle. They like for things to remain how they want. They may need to only hide certain parts of the tree, fold or unfold as they see fit. And change this whole picture only when they need to, not when the software decides to.

Edit: This is something that already happens when you contract a single item using the mouse. Basically keep the same behaviour, but multiplied for every sub-item one level below.

[vkbo]

The "inside this item" expand/collapse too exists in the context menu of any item with children. There is no feature for "just for the level below the current one". I'll think about it, but it's a rather narrow scope, and not a common feature in tree navigation in general.

[tmarplatt]

See my edit above. The functionality is already there, apparently. 😅

[nyex]

Because of a back issue I'm being forced to work mostly with keyboard only and so I came here just to ask for exactly this one set of shortcuts that seem to be missing (scrolling the viewer up and down). Any progress on this, maybe? I couldn't find anything in the docs (or randomly trying out key combinations) >.>

[vkbo]

The problem is what exactly to add. Up, Down, PgUp and PgDown all work if the viewer has focus, but you have to click for it to get focus. So the question is, what keyboard shortcuts to use.

Ctrl+Up and Ctrl+Down is already used by the project tree, so they cannot be reused without risking people reordering project items without noticing it. I'm a little reluctant to add any more modified versions of Up and Down as some are used by window managers and extension to move the whole window around.

The easiest solution is to add back a way to switch focus to the viewer so the regular keys there can be used. Currently, Ctrl+E switches focus to the editor, but I could easily make it alternate between editor and viewer, so you can use Ctrl+E to switch between them. To make that usable, I'd need to add some kind of focus indicator, otherwise you have no idea where you are.

[vkbo]

My proposal to lock the tree and require Ctrl+M to edit via keyboard is of course also a solution, which also makes it less error prone I would suspect. I'm still not certain what is the best approach. It is also why I haven't done anything about this yet.

[vkbo]

Ok, one more thought: All the relevant focus panels have a header. They currently all show some text with the default text colour, and there is a dimmed text colour defined in the theme settings (currently used for help text in Preferences, among other things). How about the tree/panel without focus has a dimmed header, and the one with focus has the standard text colour? This should make it clearer that you're switching focus between editor and viewer, and whatever tree is visible (project or novel).

I will test it out, and if it seems useful, maybe extend Ctrl+E to alternate between editor and viewer. That may be enough to solve this whole request.

[nyex]

I do think it would make more sense to have a shortcut to switch/alternate to the viewer. That was the first thing I looked for in the docs when I realized what I needed. I'm no pro-keyboard-only-user (if that's even a thing) despite using bspwm and pretending to be very nerd, though, but it seems to me having less shortcuts to memorize is always the best solution >.<

Dimmed colour sounds like an intuitive solution to me.

[vkbo]

Ok, I have a decent solution to this, and changing header text colour is a decent indicator. The dimming/brightening does catch the eye, at least for me, so it doesn't take long to get the connection.

My solution was simple enough that I'll just add it to 2.5 RC 1, and you'll be able to test it. I didn't make the RC 1 release yesterday as planned, because I didn't have the time, so I'll do it today or tomorrow.