gui: Add search bar for logging (fixes #9252)

[DAlba-sudo]

Purpose

Adds search functionality to the GUI logs. There is a conversation regarding this addition here: #9252.

Testing

I tested by building from source with the changes and ensuring that current logging functionality was persisted, as well as checking that the search bar works correctly and is reasonably performant.

Screenshots

Documentation

#9252 was the original issue that was raised.
As for documenting the code:

An input of type text is added to the logging html file, ng-keyup callback calls logging.filter.

<input type="text" id="logSearchInput" class="form-control" style="margin-bottom: 10px;" ng-keyup="logging.filter($event)">

The function logging.filter does the following:

1. If the text in the input is less than 3, it doesn't proceed with the search and "resets" the variables related to maintaining state.
2. Otherwise, the logging.entries array is searched for entries that match the query using the javascript includes function.
   • This is then added to logging.filtered array. When the logging text area is redrawn, we select the array to draw from based on whether we are filtering or not (that's why I've also added logging.isFiltering).
   • The logging.filtered array is cleared and re-parsed upon a new input.

Authorship

DAlba-sudo, d.alba.work@gmail.com

Your name and email will be added automatically to the AUTHORS file
based on the commit metadata.

[acolomb]

Will it still update the filtered view when new messages come in that match the pattern?

[DAlba-sudo]

Will it still update the filtered view when new messages come in that match the pattern?

The version in the PR does not, although it makes a lot of sense come to think of it. Let me add that in real quick. Here's what I'll do:

1. logging.filter assumes it'll be called from the ng-keyup callback, which makes it slightly hard to also place in the logging.fetch where the entries array is being updated. I'll change logging.filter to not depend on the $event being passed in, and make a 'wrapper' function to call logging.filter within the context of said ng-keyup event.
   • then I can use the same filter functionality on the current logging.fetch to update entries in real-time as they come in.

By the way, this is the first time I do a PR in a more official/organized project where I am not the owner. For cases like this where updating code in a commit is required, at what point do you prefer a new PR is made versus simple appending a commit to a PR?

Appreciate the help/patience,
DAlba-sudo

[acolomb]

Thank you. Just push more commits to this PR's branch, that's fine. It will be squashed when merging anyway.

[DAlba-sudo]

Latest push to this branch includes the following changes:

• filtered content will refresh even when no key is pressed (so long as your search query is greater than 2 characters long).
• the logs that are filtered are also sent to the logging.entries array as expected.

[calmh]

Nice, two things however... Now it's always case sensitive, instead of never. :) And I think it's quite unintuitive that nothing happens until you type the third character... I start typing in the filter field, and nothing happens, I'm not sure if it's working? Then once you reach the hidden invisible limit it does