K-Rise Systems

Had an idea while debugging today.

Some of the newer devs like myself and Shalom alike tend to clear logs so we don't need to check timestamps when running our applications. But I heard today that when working on client projects, we are supposed to not clear the logs.

The table currently has an alternating color for each row but I felt like implementing an alternating color scheme for each run of an application while keeping alternating rows would be helpful for distinguishing between the logs displayed and their associated runtime. Not sure how difficult this would be but felt it was a nice touch so I figured I would post. Super low priority and minor detail.

Gray box around one runtime and black box around the other in image below.

Tom,
What do you mean by "each run of an application"? Are you suggesting each run is like each page load/button click ?
Suman

Whenever I'm looking at logs and trying to determine which are related, I usually compare the "Started" values. When I notice a larger gap, then I generally assume that is the start of the next group of logs. So maybe the logs could thicken/darken the border between 2 logs if the "Started" values are far enough apart?

A similar suggestion was this one I made for highlighting any new logs since last refresh. There's some overlap, but I feel they each can be valuable in their own ways.
viewtopic.php?p=229

SumanPrasad wrote: ↑March 16th, 2022, 12:28 pm Tom,
What do you mean by "each run of an application"? Are you suggesting each run is like each page load/button click ?
Suman

Yes, in my case the runtime of the applications I've built so far are pretty short. So for example, if I'm testing a button or just what occurs on page load. If they run in close enough proximity to each other with regards to "Started values", then I would consider that the full runtime of the aspect I'm testing. Like Jeffrey mentioned below, it could be sortable by the proximity of "Started values". There could be cases where this wouldn't work however, like if something was to run for a long time and thus be far from the prior log record.

JefferyD wrote: ↑March 16th, 2022, 1:14 pm Whenever I'm looking at logs and trying to determine which are related, I usually compare the "Started" values. When I notice a larger gap, then I generally assume that is the start of the next group of logs. So maybe the logs could thicken/darken the border between 2 logs if the "Started" values are far enough apart?

A similar suggestion was this one I made for highlighting any new logs since last refresh. There's some overlap, but I feel they each can be valuable in their own ways.
viewtopic.php?p=229

I use the same method to check currently. I tend to just drag out that column and check the started column against my clock or against recent values to see it matches close enough to when I ran the application/component. Your point about the "Started" values is nice to mention because I sort of took it for granted in my approach when describing my intentions here.

I think your forum post has the same intent like you said, with a slightly different and arguably maybe more thorough analysis on implementing this feature. I agree that both perspectives can be valuable and do think simply bolding the newer logs could be much faster to implement. (I didn't read yours prior to posting my suggestion.)

I have a suggestion:
logs will be bolded (or styled differently) to show that this record has not been visited in the current session (like links in webpages changing from blue to purple).
once the log is opened it will become "un-highlighted".
So when looking at records you can open the newest record then generate more and they will be "highlighted" as unopened.
it can be made to retain this history for page reloads.
this should be easy to implement, would it be helpful?

steve.sakhnini wrote: ↑March 17th, 2022, 11:12 am I have a suggestion:
logs will be bolded (or styled differently) to show that this record has not been visited in the current session (like links in webpages changing from blue to purple).
once the log is opened it will become "un-highlighted".
So when looking at records you can open the newest record then generate more and they will be "highlighted" as unopened.
it can be made to retain this history for page reloads.
this should be easy to implement, would it be helpful?

This is also a viable approach, with potentially some additional functionality. I don't know how difficult each implementation would be myself.

I think it would be helpful personally. But I certainly am starting to manage with logs just fine. But I figured it was still worthwhile to implement at some point in the future.

steve.sakhnini wrote: ↑March 17th, 2022, 11:12 am I have a suggestion:
logs will be bolded (or styled differently) to show that this record has not been visited in the current session (like links in webpages changing from blue to purple).
once the log is opened it will become "un-highlighted".
So when looking at records you can open the newest record then generate more and they will be "highlighted" as unopened.
it can be made to retain this history for page reloads.
this should be easy to implement, would it be helpful?

It would be helpful, but I'm not sure if that's the best approach. Will it save per log or per user, and will there be a way to "un-highlight" it?
I know that the tabs already persist, so maybe a pin icon could be added to any logs in the list that have an opened tab. It's a different feature that I'm suggesting, but it could easily be used in the way you suggested. And it would offer the option of removing the icon by closing the tab as well.

Here is an example of how I picture it working. I also added an example of my idea for separating logs by started time. I imagine a minimum time gap selectable by the user that controls how much of a gap is needed before a time gap separator is generated.

The original suggestion is related to task 11048.