Project Tree View: Edit Indicator

[awqk]

Double-clicking a tree view item opens the document in the editor.
Single-clicking a tree view item only changes the tree view selection, but leaves the editor as is.

People visually oriented to look at the tree view (like me), may get disoriented when the document highlighted in the tree view is not actually in the editor. The more I navigate, the more likely this is to happen. I know there is the fine print on top of the editor panel, but I am not yet in the habit of looking there first.

Some edit indicator in the tree view might help, like swapping the document icon for an edit symbol, or whatever else Qt might have on offer. It should be clearly visible, though.

[vkbo]

The selection is separate from the action because of keyboard shortcuts. The tree is navigated by the keys, so the trees need to respond to single selection without triggering any action (other than updating the details panel below).

I have no idea what the edit indicator is meant to do. I don't understand the request here.

[awqk]

I want to look at the project tree and see which document is open in the editor. Hint: It's not 'Page'.

[vkbo]

Click the header of the editor, and it will show you.

[awqk]

I could also just read the header of the editor, which is easier than clicking it, but you fail to get the point. I want to see it only by looking at the tree view. Do you know any other multi-document editor without this kind of visual feedback?

[vkbo]

Please dial back the tone. My patience is starting to wear a little thin.

Clicking the header will select the document in the tree, which helps locate it. Reading the header does not provide the same instant feedback. Those are clearly different levels of feedback.

VSCode's own visual feedback is to auto-select whichever document has focus, which is what clicking the header is modelled after, except the auto-select in VSCode is an incredibly annoying feature, so I made it click-activated in novelWriter. I can add an opt-in preference setting that makes novelWriter behave the same way as VSCode.

Qt does not provide any feature of the kind you're describing.

[awqk]

Please dial back the tone. My patience is starting to wear a little thin.

Sorry, I didn't mean to offend.

VSCode's own visual feedback is to auto-select whichever document has focus, which is what clicking the header is modelled after, except the auto-select in VSCode is an incredibly annoying feature, so I made it click-activated in novelWriter. I can add an opt-in preference setting that makes novelWriter behave the same way as VSCode.

Proposed desired result: the selection marking (white font on blue background) always shows the document open in the editor.

Proposed next best result: Something else to give visual feedback (in the tree view) which document is opened, for example, by swapping the icon.

Perhaps the opt-in setting you propose is the solution, though losing the undo history on right-click could be a problem.
(I assume that a single-click in the tree-view widget you use automatically selects/highlights the item, and also that opening the right-click context menu selects/highlights the item underneath. You do not want to switch the editor document and lose the undo history every time this happens, this might be one of the reasons why you implemented it this way.)

Qt does not provide any feature of the kind you're describing.

Looking at VSCode, a right click only paints a frame around the item under the cursor, without switching the editor. I wonder if something similar is doable with the tools you have on hand:

• leave the selection marking (white font on blue background) on the double-clicked, editor-opened document, and never move it
• highlight the single-clicked (right-click-context-menued) item only by painting a frame around it.

[vkbo]

Assuming we're using the Qt-provided widget:

Proposed desired result: the selection marking (white font on blue background) always shows the document open in the editor.

This can't be done. You have to be able to select entries in the tree, and that is how the widget does that,

Proposed next best result: Something else to give visual feedback (in the tree view) which document is opened, for example, by swapping the icon.

I'm not going to design a double set of icons, and if the goal is visibility, it's the least visible of all possible solutions.

Perhaps the opt-in setting you propose is the solution, though losing the undo history on right-click could be a problem. (I assume that a single-click in the tree-view widget you use automatically selects/highlights the item, and also that opening the right-click context menu selects/highlights the item underneath. You do not want to switch the editor document and lose the undo history every time this happens, this might be one of the reasons why you implemented it this way.)

That's not what I propose at all. When you click the document header, the corresponding item is selected in the tree. This works for both editor and viewer. It does nothing other than select the document though. Automatically opening documents won't be implemented on single select.

What I am proposing is that when the editor or viewer receives focus, the selection process triggers in the same way, to indicate which document you're viewing. Exactly what VSCode does. However, in VSCode it is done by activating tabs, which novelWriter doesn't have.

Qt does not provide any feature of the kind you're describing.

Looking at VSCode, a right click only paints a frame around the item under the cursor, without switching the editor. I wonder if something similar is doable with the tools you have on hand:

No. There is only one selection mode. Which is the one you want to re-purpose.

To get what you are proposing, a new tree view has to be written from scratch, using custom paint functionality. That's not going to happen, both because it is a lot of work to create a non-standard behaviour, and it would be far too slow to implement in Python. This is the kind of stuff you do in C++.

[vkbo]

A possible solution is to highlight the row corresponding to the edited document, like is done in the Novel View. The Novel View uses an alternate background colour for all headings in the currently open document. It is also possible to change the font colour for the item.

[awqk]

Darn! You are too fast, I was about to suggest the exact same thing. Both use QAbstractItemView class, it seems. I do think the color scheme could be a tad more visible than it is.

[vkbo]

It repurposes the alternate row colours for this effect, but since the alternate row colouring isn't enabled, it works. It's not very visual, but it's possible to tweak the colour theme. It doesn't work for the Qt Default theme though, which is just system or library defaults.

Neither use QAbstractItemView, but the QTreeWidget which implements all the painting in the C++ library. The only custom list view in novelWriter is the Welcome dialog project list, but it isn't designed to be a large list.

[awqk]

Actually, contrast is better now after the switch to another colour scheme and back to Default Light.
Maybe there was a colour scheme change recently that didn't update existing configurations.