Is your feature request related to a problem? Please describe.
I regularly encounter situation where I'd like to find a process in btop's process list without wanting to hide other processes. As an example, consider a situation where one would like to take a closer look at a process spawned in an SSH session, in a tmux session or within a nix (as in NixOS) build process. In these situation it's usually very useful to also have a situational awareness of the ancestors of the process under consideration.
Describe the solution you'd like
The solution I personally would find most intuitive would be for the "delete filter" action (i.e. when pressing the del key after having searched for processes) not to clear the current process selection. Say I'm filtering for bash and have selected one specific process -- with this change pressing del would simply switch the process list to displaying the entire process tree again while keeping the selected bash instance still scrolled into view (ideally in the middle of the list) and the selection active. It would then be rather easy for me to look throught the process' immediate surrounding subtree.
Ideally, that behavior would also work the same if I changed to a view that gets re-sorted very often (say direct cpu) so I could "follow" a process that is active in bursts and thus currently vanishes from view very often. This should also make killing such a process much easier in such scenarios. Also, if this behavior would also work when switching between sorting strategies, one could more easily have a look at multiple aspects of the same process (say: cpu, memory, number of threads) without "losing" it.
Describe alternatives you've considered
As an alternative, I can imagine having a similar behavior tied to having the "info" bar of a process active could also work well, i.e. if one selects a process and presses enter, the info bar is displayed and the process is "selected" (i.e. marked) with a different color than the "normal" selection. The process could then stay similarly scrolled into view as described above unless the user selects another process with the arrow keys (the selection vanishing upon a press on enter is already the current behavior). Having essentially two different selection types might make navigating frequently changing views like direct cpu simpler, as "following around" a process would still be a more conscious (opt-in) decision (and opening a process' info already indicates interest in that specific process).
gabyx
commented
1 week ago
Is your feature request related to a problem? Please describe. I regularly encounter situation where I'd like to find a process in btop's process list without wanting to hide other processes. As an example, consider a situation where one would like to take a closer look at a process spawned in an SSH session, in a tmux session or within a nix (as in NixOS) build process. In these situation it's usually very useful to also have a situational awareness of the ancestors of the process under consideration.
Describe the solution you'd like The solution I personally would find most intuitive would be for the "delete filter" action (i.e. when pressing the
delkey after having searched for processes) not to clear the current process selection. Say I'm filtering forbashand have selected one specific process -- with this change pressingdelwould simply switch the process list to displaying the entire process tree again while keeping the selectedbashinstance still scrolled into view (ideally in the middle of the list) and the selection active. It would then be rather easy for me to look throught the process' immediate surrounding subtree.Ideally, that behavior would also work the same if I changed to a view that gets re-sorted very often (say
direct cpu) so I could "follow" a process that is active in bursts and thus currently vanishes from view very often. This should also make killing such a process much easier in such scenarios. Also, if this behavior would also work when switching between sorting strategies, one could more easily have a look at multiple aspects of the same process (say: cpu, memory, number of threads) without "losing" it.Describe alternatives you've considered As an alternative, I can imagine having a similar behavior tied to having the "info" bar of a process active could also work well, i.e. if one selects a process and presses
enter, the info bar is displayed and the process is "selected" (i.e. marked) with a different color than the "normal" selection. The process could then stay similarly scrolled into view as described above unless the user selects another process with the arrow keys (the selection vanishing upon a press onenteris already the current behavior). Having essentially two different selection types might make navigating frequently changing views likedirect cpusimpler, as "following around" a process would still be a more conscious (opt-in) decision (and opening a process' info already indicates interest in that specific process).