[Log Viewer] Make the width of columns resizeable

[nelsonaponte]

The problem

In many cases, the standard width of columns is too long for most records in that column, leaving little space for data in other columns.

Your suggestion

The width of each column should be easily and dynamically manageable with the cursor so users can modify it as it better suits them.
When the column is not long enough for the data contained in one of its cells, the data from that cell should be wrapped in the cell.

When the height of a cell increases or decreases, the size of the whole row should increase or decrease accordingly.

Your environment

runtimeInfo:
  version: 4.3.0
  buildString: Release Build
locale: en-DE
systemInfo:
  configFolder: /etc/openhab
  userdataFolder: /var/lib/openhab
  logFolder: /var/log/openhab
  javaVersion: 17.0.13
  javaVendor: Red Hat, Inc.
  javaVendorVersion: (Red_Hat-17.0.13.0.11-1)
  osName: Linux
  osVersion: 5.4.60-v8.1.el8
  osArchitecture: aarch64
  availableProcessors: 4
  freeMemory: 309470264
  totalMemory: 730857472
  uptime: 489198
  startLevel: 100
clientInfo:
  device:
    desktop: true
    edge: false
    ie: false
    firefox: false
    macos: true
    os: macos
    pixelRatio: 2
    prefersColorScheme: dark
  isSecureContext: true
  locationbarVisible: true
  menubarVisible: true
  navigator:
    cookieEnabled: true
    deviceMemory: N/A
    hardwareConcurrency: 8
    language: en-US
    languages:
      - en-US
    onLine: true
    platform: MacIntel
  screen:
    width: 1470
    height: 956
    colorDepth: 24
  support:
    touch: false
    pointerEvents: true
    observer: true
    passiveListener: true
    gestures: false
    intersectionObserver: true
  themeOptions:
    dark: dark
    filled: true
    pageTransitionAnimation: default
    bars: light
    homeNavbar: default
    homeBackground: default
    expandableCardAnimation: default
    blocklyRenderer: null
  userAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15
    (KHTML, like Gecko) Version/18.1.1 Safari/605.1.15
timestamp: 2025-01-01T09:16:29.042Z

Additional information

[cdjackson]

In many cases, the standard width of columns is too long for most records in that column, leaving little space for data in other columns.

Are you aware that you can scroll the window left/right to only show the message (since that's normally what is most interesting)? For example.

to -:

When the column is not long enough for the data contained in one of its cells, the data from that cell should be wrapped in the cell.

Personally, I would be against this. Wrapping text in a log viewer makes the data less uniform, and hard to "filter by sight" - ie looking for certain patterns as things scroll past.

[nelsonaponte]

I believe the power of logs is not just to help you spot an issue but also to help you understand and fix it.

In your case (very long log messages), I'm surprised you got accustomed to working with them in a single line. Even if you scroll right and leave only the timestamp and message, how can you spot something by "sight" without the program highlighting it when that text is still outside the area you can see and when the logs are generated very fast? I don't know how I could find what I can't see.
In my case (short messages, as in the screenshot below), scrolling right as you suggested would do most of the time.

However, our brains are used to having a delimiter when reading and skipping to the next line to continue (think of books, magazines, websites), regardless of the language (romance languages, Arabic, Japanese, etc.). Even the log viewer in the Karaf console wraps the text.

So, even after you spot the log you need, having to scroll and scroll right to read seems unnatural and makes the text hard to understand. Proof of that is the exception message. It's hard to understand it when it's just one line. Hence #2961.

Plus, people could shorten or increase the column size to their needs. You could still have super wide columns and the row's height would be 1 line.

[cdjackson]

I believe the power of logs is not just to help you spot an issue but also to help you understand and fix it.

Of course, and the viewer attempts to help with that by providing filtering and highlighting.

Even if you scroll right and leave only the timestamp and message, how can you spot something by "sight"

Often I'm looking for sequences - normally, these are at the start of a line, so the end doesn't matter (as much) for the initial "spotting". If there is line wrap being used, then the start of a line is now intermixed with the middle/end of other lines.

I've been doing this a long, long time :) With all the log viewers I use, they do not provide line wrap...

Proof of that is the exception message

The exception message is different - it is meant to be displayed with multiple lines. It has CR LF embedded in the message and I agree the viewer should respect messages that are meant to be displayed across multiple lines. I've said that on the forum, and as I said above, I've already produced a fix for that and will provide a PR at some point soon. However, normal messages are not meant to be split across lines - at least they were not intended to be by the developer or they would have put in the appropriate line breaks (line the stack trace has).

Personally I won't be spending time at this stage to implement variable columns and the ability to display or remove columns to achieve essentially the same thing as we have now (but without the wrap). If you want to do so, then I'm happy to look at a PR, and I do agree that with some work, it would be possible to produce something that can be configured to meet a wider set of user needs - but I don't currently have the time to work on that myself.