Quick Question

[BetterRed]

Originally Posted by KevinH

I played around with this but dropping the highlight when focus is lost just does not work.

Every time a user clicks on a place in Preview to sync with CodeView the highlighting would be lost as Focus goes to Preview so you can not tell where you are after the sync (or that the sync even happened at all if no scrolling is involved). Similar problems happen with Find and Replace as it takes the focus but you can not easily see where you are finding and replacing as the highlight is lost.

I am afraid that is something that too many users rely on (ie - I do!) and so we will not drop current line highlighting when focus is lost as there are many outside windows can can and will interact with the CodeView window but are outside of focus.

Fair enough.

Removing the display line highlight was a suggestion to indicate that the CV window does not have keyboard focus. Panels such as the Book browser and ToC change the background colour of the current item (see third screen shot below) when they don't have focus. Perhaps a similar approach could be applied to the current display line in the CV panel; on reflection, that would be better than removing the highlight.

Originally Posted by KevinH

Sorry, but your window manager should be making things clear when focus changes by dropping/showing the insertion point cursor. So looking to see when the blinking cursor is in a window is the best way to tell if that window is able to accept keyboard input.

If you have trouble seeing the cursor, please try using Windows Accessibility features to help make it more clear (that does work with macOS Accessibility settings so it should with Window's as well).

Which is precisely what I did decades ago, viz:



Here you see compliance with that setting in Sigil's metadata editor :



Here you see non-compliance with that setting in Sigil's Code View panel:



Sigil is no Robinson Crusoe in this regard, the calibre editor and most browsers, text editors etc, don't comply with that setting either.

I don't really want to continue this discussion, the underlying deficiency presumably lies within Qt, and in this instance perhaps deeper than that. It's probably one of those deep-seated 'bugs' that some regard as a 'feature'

BR

[KevinH]

Originally Posted by BetterRed

Panels such as the Book browser and ToC change the background colour of the current item (see third screen shot below) when they don't have focus. Perhaps a similar approach could be applied to the current display line in the CV panel; on reflection, that would be better than removing the highlight.

This is quite easy to do. On loss of focus invoke HighlightCurrentLine, and on regain of focus invoke HighlightCurrentLine, and then modify that routine to check if CV has focus to determine what background colour to highlight with.

As proof of concept, I used the line# background color to highlight the current line when no focus and the normal highlight the line color when it has focus.

This makes detecting if has focus or not much easier, while still allowing easy visual syncing between Preview and CodeView and with the various other dockwidgets.

If that colour combination works for you, I could easily push this to master.

[BetterRed]

Originally Posted by KevinH

As proof of concept, I used the line# background color to highlight the current line when no focus and the normal highlight the line color when it has focus.

If that means this:



Then that would be perfect I like symmetry.

BR

[KevinH]

Good. I will push that to master today.

FWIW, the BookBrowser highlight colours are inherited from the underlying OS to match what it typically does (at least that is what it does for most colours used). We choose, and users can set, the Line# Background colour (it is not inherited from the OS). It just happens to be the same in your case.