Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problems rendering super wide columns #2879

Open
philrz opened this issue Nov 3, 2023 · 2 comments · Fixed by #2881
Open

Problems rendering super wide columns #2879

philrz opened this issue Nov 3, 2023 · 2 comments · Fixed by #2881

Comments

@philrz
Copy link
Contributor

philrz commented Nov 3, 2023

Repro is with Zui commit e7febec.

What's shown in the video below all starts from the data returned by this query:

get "https://api.github.com/repos/brimdata/zed/pulls?state=all&sort=desc&per_page=3"

When viewed as the array of big nested records that it is, Zui displays the output in a summary format that shows where it's been truncated and provides hints to the user where they might want to expand it to look at nested values.

Problems becomes visible if we ask to render the output as a string via line mode.

get "https://api.github.com/repos/brimdata/zed/pulls?state=all&sort=desc&per_page=3" format line

Three problems now become visible:

  1. The column is crazy wide such that the text is very difficult to read. @jameskerr has mentioned that the default size of the column needs to be capped. I imagine a hint should also be shown to the user that they're seeing a truncated value.
  2. When we scroll horizontally so we're looking at the rightmost data in the column, when I try to highlight and copy/paste the string contents, what I highlighted does not line up with what comes out of my paste buffer.
  3. Despite the column being super wide at the current defaults, we do see the rightmost part of the value is indeed truncated. This is evident by the fact that we know it to be a string representation of valid JSON, and can be further validated if we tack on | yield this[-50:] to see just the 50 rightmost characters in the string. This confirms that almost all the value was being rendered.
Repro.mp4
@jameskerr
Copy link
Member

Did not know I could write a "get" in zui.. Wow

@philrz philrz linked a pull request Nov 7, 2023 that will close this issue
@philrz
Copy link
Contributor Author

philrz commented Nov 7, 2023

The attached video shows how things have improved thanks to the changes in linked PR #2881.

  1. The width of the super wide column is now capped at a reasonable limit.
  2. When I scroll right and then highlight/cut/paste part of the value, what ends up in my paste buffer is now what I highlighted.
Verify.mp4

That said, some things could probably still be improved.

  1. While the super wide column we had before was buggy, the one thing it had going for it was that it made it possible to see almost the entire value by scrolling right. The video shows the only way I was able to come up with inside Zui to see the value now which involves a clunky struggle with dragging the column heading rightward bit by bit before using the horizontal scrollbar, which would get super tedious with an enormous value like this. I ultimately remembered that I could right-click and select "Copy" and the entire value would indeed end up in my paste buffer so I could view it outside Zui. However, I'm not sure all users would make this leap on their own, and requiring them to leave Zui is suboptimal. @jameskerr and I discussed this and one possibility he floated was to maybe make the whole string value somehow easier to see if the user opens the row up in the Detail view, which is due for some enhancement anyway.
  2. It would be helpful to have some kind of visual cue at the right-hand side of cell containing a truncated value (e.g. ...) so the user knows the value in the column has been truncated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants