Extend & improve available keyboard shortcuts

[bentolor]

A few additional key binding which come into my mind might enhance the UX:

key	function
h, ?	show keyboard usage help page
→ or n	expand collapse node (current) or navigate down on collapsed, or navigate to next element in list on collapsed entries. hence you can traverse whole tree w only key
←	similar: collapse or navigate to previous entry for collapsed entries
Pos1 / End	jump to first/last entry respectively
PgUp / PgDown	jump one page up/down respectively
Tab	The current handling is a little confusing. Especially inside JSON Payloads where ← & ↓ toggle between {"POWER":"ON"} and ... a different visualization. See here: . IMHO Tab should always switch panes and navigation keys (arrows, pgup/dwn, pos1/end) should work respectively.
g	Opens a navigation entry bar at bottom to directly jump to a node. i.e. typing sth. like val.r.mapda would navigate to valuetudo (root node), then on . open that node navigate to rockrobo then same on . then MapData so that eventually valuetudo.rockrobo.MapData node is selected. Saves keyboard stroken when you actually now/see the node you want to open. Search should maybe start from the current cursor position. I have sth. that like searchbox in mind, where entering ja.la.str naviagtes you to String.

[EdJoPaTo]

The current handling is a little confusing. Especially inside JSON Payloads where ← & ↓ toggle between {"POWER":"ON"} and ... a different visualization.

That actually is a feature: When you select a key inside the JSON only that key is shown in the history. This is especially neat with numbers on a specific key which can then be plotted in the graph when the key is selected. I agree its a little confusing with a simple JSON like yours in that case.

Pos1 / End jump to first/last entry respectively PgUp / PgDown jump one page up/down respectively

Knowing the "pages" (height of terminal) is probably not that easy and might not be that helpful for less things opened in the view. But jumping +10 or -10 should be relatively simple to do.

g Opens a navigation entry bar at bottom to directly jump to a node. i.e. typing sth. like val.r.mapda would navigate to valuetudo (root node), then on . open that node navigate to rockrobo then same on . then MapData so that eventually valuetudo.rockrobo.MapData node is selected. Saves keyboard stroken when you actually now/see the node you want to open. Search should maybe start from the current cursor position. I have sth. that like searchbox in mind, where entering ja.la.str naviagtes you to String.

fzf comes in mind when reading this.

← similar: collapse or navigate to previous entry for collapsed entries

This should already work?

(I only stated thoughts on the ones I had thoughts about. The rest are relatively straight forward ideas. Implementation might be different but I like the ideas.)

What also comes to mind here is the current handling of the mouse clicks which is… rough.

[TotalKrill]

I have some mouse clicks additions to my branch here branch. It also contains the tls-support :)

[EdJoPaTo]

awesome! Feel free to put them on a separate branch and provide a PR :blue_heart:

I also started some improvements locally about page up / down logic but that was never finalized :disappointed:

[EdJoPaTo]

Home/End/PageUp/PageDown are added in 020a179 and bc2ad8e

h/j/k/l are currently used as arrow keys (like in vim). Therefore h for help wouldn't work. Maybe a bar at the bottom displaying the currently relevant keys all the time (like in htop or nano?)

For the navigation I am thinking about the / like it is with less or vim to search with a regular expression. n then jumps to the next, N to the previous hit.

[YAMLcase]

for the mouse clicks suggestions, I think single-clicking on a different topic should select AND open it

[EdJoPaTo]

Thank you for the ideas @YAMLcase!

The current behaviour is selecting an unselected topic on click. When it’s already selected, it’s toggled. A double click on an unselected one therefore selects and toggles it.

When it directly does both it could open / close more than wanted? 🤔

[EdJoPaTo]

Keyboard usage is shown in the bottom bar now. Traversing the whole tree with → seems not that intuitive, so I don't think I'll add that. g seems like a more complex feature with fuzzy logic. A simpler search is currently discussed in #145.

I think all the ideas in here are addressed?

[bentolor]

Thanks for the update! I think even a simpler topic search already does the trick. So I think all addressed. Thanks!