rivo / tview

Terminal UI library with rich, interactive widgets — written in Golang
MIT License
10.69k stars 560 forks source link

Long line in TreeView is simply cut #707

Open LukasRauth opened 2 years ago

LukasRauth commented 2 years ago

Hi! Great tool you are providing here! We use the TreeView feature to show hierarchical data from the command line. It works well but if a line is too long to fit into the given width it is simply cut and there is no way to get the information from that line after the cut, except for zooming out quite a lot.

Using the left/right key just jumps one line up or down.

It would be nice to just wrap the text around or make the view left/right scrollable.

Thank you a lot!

image

rivo commented 2 years ago

I will most likely not introduce wrapping around and it would add tremendous complexity to this component. But I'm open to add horizontal scrolling.

I'm open for ideas.

On a side note, I think it might be better to put longer JSON strings into a separate window than to fit them into a tree view line.

darkdragon-001 commented 2 years ago

I suggest scrolling the entire tree view by about 90 characters when pressing right arrow key and scrolling back when pressing left arrow key similar to the less terminal utility. Using up and down arrow keys to scroll/navigate up/down.

rivo commented 2 years ago

Yeah, I was hoping for a suggestion that would preserve the current behaviour for trees that fit the screen.

rivo commented 1 year ago

Let me phrase this differently: We need a solution that is backwards compatible. The left/right arrow keys are already used. The other questions I listed above also need to be answered before I can start.

If there's no or little interest, I will close this issue.

kampanosg commented 6 months ago

Hey @rivo!

Resurrecting this, instead of raising a new issue 😅 I have the same problem/need. Some sort of horizontal scrolling in TreeView would be awesome. Let me know if I can help or contribute to this 😄

P.S: Thank you for tview. I love it 🤟

rivo commented 5 months ago

@kampanosg I posted a list of questions above which need to be addressed first. Maybe you can provide some insight based on your specific application, which could help us figure out a good solution.

Macmod commented 2 months ago

I will most likely not introduce wrapping around and it would add tremendous complexity to this component. But I'm open to add horizontal scrolling.

  • A possibility is to scroll when the text doesn't fit and the user hits the right arrow key. If the text fits, the right key would move the selection down as before (mostly for backwards compatibility reasons).
  • Do we want to scroll in steps of one or jump by, say, 5 characters at a time?
  • Should all lines scroll or just the selected one?

    • I would have said "just the selected one" but there might be a case where you need to read a long line although it is not selected (especially since not all lines may be selectable).
    • But if it's "all lines that are too long no matter what's selected", then the idea of using the right/left arrow might break existing systems.
    • We can also scroll the entire tree view instead of just individual lines.
  • We can also bind other keys for scrolling.

I'm open for ideas.

On a side note, I think it might be better to put longer JSON strings into a separate window than to fit them into a tree view line.

I agree with others that this is an important feature. In my app I try to arrange all information using Flex because the data that is going to be loaded does not have predictable dimensions, thus giving the user more flexibility to increase or decrease the size of things he wants to read by resizing the window. So I have a couple Flexes and inside them other components that hold data. Tables are fine, but TreeViews simply put a hard limit on what the user can see, which is ultimately limited by his maximum window size (of course the user can be "sneaky" and figure out he can also get more space by changing the font size, but that's not ideal).

In my opinion:

In my app for example I even override the right/arrow keys to expand/collapse nodes, because I don't like having horizontal keys moving vertically, so in my case I wouldn't mind much if this was implemented. If someone does mind and wants both behaviors to work "somehow", I believe (but please correct me if wrong) they could define their own handler that just selects the previous/next node using other keys.

I don't have a solution, but I wanted to share these thoughts to the discussion :-)