frontend: Add toggle wrap for logViewer and fix log viewer styles#3124
frontend: Add toggle wrap for logViewer and fix log viewer styles#3124vyncent-t wants to merge 2 commits intokubernetes-sigs:mainfrom
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: vyncent-t The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
6eaabb4 to
a8566bc
Compare
a8566bc to
9adfd3e
Compare
joaquimrocha
left a comment
There was a problem hiding this comment.
Besides my comments, I noticed that when we wrap the text, the vertical scroll bar is now pushed beyond the limits of the dialog, meaning we lose the ability to understand where we are vertically.
| } | ||
|
|
||
| // // this function manually formats the logs to a single line. | ||
| // // currently we must manually format the texts as addonFit does not work with multiline texts. |
There was a problem hiding this comment.
Can you elaborate on this? I don't understand exactly why this function is needed. Are you sure there's no way to delegate this to the xterm component?
There was a problem hiding this comment.
I have tried using options for single line printing but it had a few issues.
the format to single line is needed since the log "lines" are not actually single line text strings but rather a bundle of log lines, which I found the terminal has trouble formatting it correctly. It also dynamically sets the width depending on the longest singular line, which that value I use to fix the width sizing.
(while the split new line \n is read properly by the console log, in the xterm it was not)
logs w/no timestamp
There was a problem hiding this comment.
side note: I was responding in the context of you meaning "delegate" to the xterm comp as in using the built in options to handle the single line format printing (changing width, using addonFit, etc.) but if you mean in terms of moving this function from a stand alone into the main log viewer component I moved it there as well.
0a54b04 to
2996431
Compare
|
e2e tests are passing, none of the log changes cause it to fail. going to drop e2e test changes here and rebase when #3144 is merged |
563db9c to
07ffb46
Compare
|
|
||
| it('returns 0 for empty input', () => { | ||
| expect(findLongestLine([])).toBe(0); | ||
| }); |
There was a problem hiding this comment.
please add a test case like ["abcde", "egf\nabc"], I think the current implementation doesn't handle a case like that
There was a problem hiding this comment.
I think 'splits on real LF (\n) for a line' covers it since the new version of the findLongestLine uses .split(/\n|\n|\r/) so should split as needed but I added an another one with ["abcde", "egf\nabc"]
07ffb46 to
2e3adbf
Compare
| }); | ||
|
|
||
| it('splits on real LF (\\n) for a line - longer', () => { | ||
| expect(findLongestLine(['abcde', 'egf\nabc'])).toBe(5 + 1); |
There was a problem hiding this comment.
the longest line in this case is abcdeefg and is 7 characters long
There was a problem hiding this comment.
there isn't any joining after the function finds a new line or return syntax, it treats every "main string" (bundle of logs in live) as a collection that needs to be split up into parts and substrings and we count off those smaller parts
the inputs of ['abcde', 'egf\nabc'] are broken into ['abcde', 'egf' abc']
we then add a +1 on every line for the longest to make up for splitting the \n (it also makes sure the width is set to exactly the number of chars +1 to ensure a fit every time)
so the function should read
abcde as 6 long
efg as 4 long
abc as 4 long
There was a problem hiding this comment.
yes I understand that currently the function works this way, but what I'm saying is that the function needs to be adjusted so it passes this test since it something we might encounter and it should properly count the line length
There was a problem hiding this comment.
okay I think I see what you're saying, you mean that in the event the logs are chopped up like this
["this is a long line that for this current example that","for some reason\n we split"]
we should have it so that it doesn't break visually. I was confused as I only seen related logs paired together.
2e3adbf to
f98572a
Compare
e84a9e3 to
f40b78c
Compare
|
blocked here due to new issues:
|
|
new issues
|
new issues
|
c1d21a1 to
febba81
Compare
made some changes and I am now using grid for the space filling, will keep the non pod log viewer the same style of stacking since it does not have the space for it ref: just adding as a visual ref for |
7a68143 to
d0bbf9b
Compare
|
last push:
|
91fb417 to
82e9374
Compare
|
May need to settle with the bottom spacing imperfections when not using wrap texts (toggling wrap text off) for some log windows. This is only an issue for logs that do not contain enough lines to fill out the rest of the spacing when reformatting to unwrap. I have also tried experimenting with creating a custom scroll bar just for this view and that introduces too many issues for what it is trying to accomplish (having to sync it to the 'real' scroll bar, having format issues with other switches due to needing nested boxes, etc.) and will be abandoning that idea. Although I have been able to succeed in making the unwrap view work along with the Prettify option where it preserves the JSON readable format but with unwrapped lines. |
…g viewer style - Adds a toggle switch in the log viewer that allows for texts to be wrapped on/off - Fixes issue where log viewer buttons were not aligned correctly Signed-off-by: Vincent T <vtaylor@microsoft.com>
…and add wrap toggle switch
82e9374 to
ad1d907
Compare
|
xterm seems to be way limited, I think we should consider some alternative instead, that's more geared towards displaying logs instead of terminal emulator |
|
PR needs rebase. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |






This PR adds a toggle button for the Logs Viewer window that allows the text to be formatted for word wrap. There are also style formatting issues that I have noticed and made an issue for here #3052 this PR also adds changes that style error while also.
Changes
Introduces new Wrap option for log viewer component to allow toggle between default text formatting and word wrap
Introduces new format and tooltip context for log viewer buttons
Fixes rendering for small view
How to test
Fork PR from original: #3027
requested feature from #2657