Added filters for Name and Type

[tyrone-wu]

Added input fields for filtering Name and Type of BPF program. #5

[jfernandez]

Thanks @tyrone-wu. I'll make sure to check it out tomorrow. It would help to provide screenshots or a video of the new feature.

[jfernandez]

Could you also squash the commits into just one?

[tyrone-wu]

The commits are squashed now. 👍 (and sorry about the messy forced pushes 🙃)
And here's a small demo of filters in action.

[jfernandez]

Looks great. I'll take a closer look this weekend

[jfernandez]

@tyrone-wu I tried it out today and have some feedback.

I'm concerned about using up all space in the footer. If we were to add more features, there wouldn't be much room left. I suggest just adding another option to to the existing footer to toggle the filter input field, something like this:

(q) quit | (↑,k) move up | (↓,j) move down | (↵) show graphs | (f) filter

When f is pressed, then show the filter input.

Also, I think we only need one filter field that works on both the name and type of the program, we don't need separate ones.

Remove the blinking, I don't think it helps. But I like the golden border color.

[tyrone-wu]

For the graph and table state of the UI, would it be alright if I refactor it to use a Mode enum instead of the show_graphs bool for representing the UI state? I was thinking of using the Mode enum to have it also hold a Mode::Filter state (and also possibly in the future a sorting state for #2).

Some of the refactoring would end up looking something like this:

match app.mode {
    Mode::Table => match key.code {
        KeyCode::Down | KeyCode::Char('j') => app.next_program(),
        KeyCode::Up | KeyCode::Char('k') => app.previous_program(),
        KeyCode::Enter => app.toggle_graphs(),
        KeyCode::Char('f') => app.toggle_filter(),
        KeyCode::Char('q') | KeyCode::Esc => return Ok(()),
        _ => {}
    },
    Mode::Graph => match key.code {
        KeyCode::Enter | KeyCode::Esc => app.toggle_graphs(),
        KeyCode::Char('q') => return Ok(()),
        _ => {}
    }
    Mode::Filter => match key.code {
        KeyCode::Enter => app.toggle_filter(),
        _ => {
            app.type_input
                .lock()
                .unwrap()
                .handle_event(&Event::Key(key));
        }
    },

[jfernandez]

For the graph and table state of the UI, would it be alright if I refactor it to use a Mode enum instead of the show_graphs bool for representing the UI state?

Yes, that seems like a good evolution for the code. Go for it!

[tyrone-wu]

The updated version that's ready for review!
Here's the new design:

[jfernandez]

It's almost there. I have one small request around explicitly dropping the mutex lock.

[jfernandez]

I believe by re-assigning filter you are immediately dropping the lock, which is what we want. But I would prefer doing this more explicitly, something like:

let filter = filter.lock.unwrap();
let filter_str = filter.value().to_lowercase():
drop(filter); 

[tyrone-wu]

The explicit mutex drop is added now. 👍

[jfernandez]

LGTM. Thank you for taking the initiative to add this feature and being responsive to feedback. I will cut a 0.3.0 release with this change.

[roger-cruz]

A vote of support for the filtering capability. Thanks Tyrone