Fix tree view jumparound once for all

[etosan]

I think I opened this issue back when this was under @hishamhm's care, and even that a lot changed since then, this issue is making htop so unusable that I am forced to use it less and less .. especially since competition is catching up ... which is a great pity.

Tree mode is most useful of modes for sysadmins, since it shows process hierarchies on the machine, which can deliver much more information, than pure COLUMN ordered process list.

Unfortunately as machines get bigger the process trees grow bigger as well.

Due to process being relatively cheap resource, on modern machines, the process activity, especially creation and destruction rate, is little bit higher than during the days of old.

And therein lies the issue: when you put htop into ptree mode, it constantly jumps around on the screen as processes fork and exit. Besides quick glance, you cannot really do anything useful, because exactly when you want to do some process op, the screen jumps, and you select wrong process. Bummer.

This issue is ancient. And it's becoming mighty annoying.

What is worse, I was told, back then, that due to design of the tree renderer, this issue is "unfixable".

Unfortunately, since some years ago, top, from procps-ng, which is "native" to most distros, grew ability to draw trees.

Start top and then press V (as in Shift+V) and behold: a tree! What is more concerning: Look ma! No jumping!

How they do? Woof!? Woof!?

[BenBE]

While htop tries to mitigate the jumping to some degree, it isn't fully avoidable in the current implementation as we track the selected index, not the item that's referenced through this index. Thus when the tree is rebuilt on the next update cycle, htop can only provide a good guess, where the cursor should be.

If you want to stick with a certain process, you can use Shift+f which will activate follow mode. Apart from that, when you need to select one or more processes, hitting Space to select/deselect them is also an option.

A fix for the jumping will require some rethinking of how the previous screen selection is tracked. Even simple scenarios like "sort by CPU time" open up the question: Do you want to track the current selected PID (cursor jumps on updates) or do you want to track the current line (selected process jumps). When new processes are created or old processes terminate, this becomes even more complicated.

[etosan]

@BenBE thank you for your thoughtful reply.

I know about both F and Space and use them heavily. I also know that the real solution would be quite complicated. Still, given the choice, real solution, I believe, would be preferable.

I think that by now htop has reached a maturity level, and community size, where implementing this properly is feasible, or at least possible. That is why I opened this issue.

If I were to affect the implementation, I would suggest to have dual renderer based on toggle. Eg. original vs new behavior. There probably are people out there (I don't know who, but there certainly are some) who love current behavior. I myself would prefer something little bit more intelligent, and I believe I am not the only one.

In my eyes this behavior is really important only in pstree mode. In other, "sorted modes" jumping of processes is expected "intuitively". You don't need mental locality tracking in non-pstree mode. However with trees people tend to naturally use their spatial reasoning to locate themselves in the structure.

Thinking about it a lot (really A LOT) during years, I would really prefer, if the "selected" process (the one, on which cursor is positioned) to always stayed "put" on screen. Eg. tracking the selector line offset against the top of the panel, and always scroll tree's "background" such, that "focused" process also stays pinned to that line. Eg no matter what insanity is going "above" and "below" the focused process stays put physically to certain are of screen and admin can rely on that behavior without need to F.

Regarding the times where "selected" process disappears (exits and is reaped), I would go "up", back, in the parents chain, to select new focused candidate, from last tree copy.

I never got around to think, what to do, when all these rules fail, and we need to reposition, because I cannot imagine it.

I tried to do this several times on my own in the past, but it seems I am too stupid to attempt this myself :(. These days code base diverged so much form when I played with it, that I don't think I would even understand it...

[etosan]

Is there any bounty program or some other way to nudge this?

[BenBE]

Is there any bounty program or some other way to nudge this?

There is no bounty program, but a proper PR that implements reasonable behavior without re-inventing half of the code-base will be much appreciated.