I do know that there are a bunch of settings to hide things that aren't useful, I'm just saying that even hiding things I still don't find it super useful. The table view that exists is theoretically useful, but I find that it likes to cut off information because it is, well, a table.
The VfsLogFilePatternReceiver I have never gotten to work properly. I think it's good and needed, but it definitely needs a user-friendly way of selecting a log file and viewing a live example of how it will parse the log file. Although for my purposes, we don't actually write to a log file, so it's a bit of a moot point. The next question of course is what do I feel would be better? I spent some time working on that tonight as a proof of concept, and here's what I came up with(with chainsaw in the background for reference): [image: Screenshot from 2023-09-25 22-12-07.png] Note: this picture is from my VM, so it's definitely squashed since it was running at a weird resolution so I could take the screenshot. But this shows a good point: in this screenshot, only about 60% of the UI is actually used to view logs. From the top there's the GNOME title bar, title bar, file menu bar, toolbar, tabs, search bar, column headers, and then we finally get to what chainsaw is supposed to do - display logs. What I've done is intentionally a proof of concept at the moment, but it provides a much simpler view. Think of it like viewing logs on the terminal, but adding in the capability to do more advanced operations(e.g. what chainsaw does with the right-click context menu). The GUI is at the moment just a JTextPane instead of a table, so that fields do not get cut off(like they currently do in the table) and it can better scroll like a real terminal when new messages come in. Right-clicking will open up a pop-up menu contextually depending on what it is you have clicked on(the time, logger name, level, or the message). Anyway, that's what I personally feel would be more useful, but I would love to hear some other ideas. -Robert Middleton On Sat, Sep 23, 2023 at 11:35 PM Scott Deboy <scott.de...@gmail.com> wrote: > Please review the various display setting controls. Most of what you > mention can be toggled from visible to hidden. > > VfsLogFilePatternReceiver does exactly what you're describing. Allowing > live remote tailing of logs over an ssh accessible path. > > You control if these logs end up in separate tabs or the same tab via the > routing expression in preferences. > > We should slack sometime so I can go over the main features and what was > nuked in the log4j1 removal path and what of those are worth restoring. > > Scott > > On Sat, Sep 23, 2023, 6:08 PM Robert Middleton <rmiddle...@apache.org> > wrote: > > > Since Scott has said that he would help with maintenance and Rob T has > also > > indicated that he would perhaps help, this is my view of the current > status > > of Chainsaw and what I feel its current deficiencies are. > > > > Current status: Master builds and mostly works. The last thing that I > had > > been working on was updating the config files in order to remove xstream > > and better standardize on using commons configuration. I think some of > the > > configuration settings don't save/load correctly, but some do. All of > > log4j1 has been removed. Certain features have been removed too that > were > > largely dependent on log4j1. > > > > What I feel would be useful for Chainsaw: For me, I do a lot of embedded > > work. Most of the log files that we have at my current job just go to > > syslog on our device(syslog is provided by busybox). So viewing logs is > a > > matter of SSHing into the system and just reading from the buffer. > Having > > a utility running on a separate computer that lets me see the > > logs(especially if it can connect automatically to a device) could be > very > > useful. Specific potential use-case: at my last job, I wrote a quick log > > viewing utility that would correlate log messages between two separate > > devices. This was needed because one device was embedded that logged out > > the serial port, the other was Linux and would log over the network, but > > neither had reliable time. > > > > Current limitations that I find with Chainsaw: The current GUI is not > very > > useful. A large portion of the screen is taken up by toolbars/context > > information that I generally don't find useful. I think most of the > > features that are in the GUI are very useful(for example, being able to > > trace messages and add matches) but is limited by the fact that I only > see > > a small portion of the context at a time. In my mind, an ideal solution > > would be to get rid of the toolbars as much as possible and to focus more > > on the log messages like you would see in a terminal, but still having > the > > capability to right-click on a message/message components and investigate > > individual messages or flag them appropriately. > > > > Perhaps the best way to organize this would be to have a logical split in > > the code: the backend(which receives and routes log messages) and the > > front-end portion. The front-end could be something like Swing for a > GUI, > > or some sort of command-line interface like ncurses. > > > > Thoughts? What is something that people want to see/think could be > > useful/would want to try and code up? > > > > -Robert Middleton > > >
