A click to expand or collapse an entry in the process list tree view is often ignored

[AlexFolland]

Steps to reproduce

1. View the process list in tree view.
2. Try to expand and collapse entries to navigate around.

Observed behavior

• A click on the arrow image at the beginning of a collapsible row of the process list tree view to expand or collapse that entry is often ignored.
  • When this happens, the arrow icons all light up (get brighter), but the entry is not expanded or collapsed.
  • Clicking the arrow image multiple times, even if the click did not expand or collapse the entry, causes the "Process Details" menu to open.
• Using the left and right arrow keys to expand or collapse entries as a workaround is always ignored.

Expected behavior

• A click on the arrow image at the beginning of a collapsible row of the process list tree view is expected to always expand or collapse that entry.
• The arrow icons are expected to not change color.
• The "Process Details" menu is expected to not open from clicking the arrow icons.
• The left and right arrow keys are expected to respectively collapse and expand entries in the process list tree view.

Additional commentary

Ksysguard is another program with a process list tree view and its behavior matches the expected behavior listed above.

[hakandundar34coding]

I tested the arrows on the Processes tab. There was no expanding/collapsing problems.

Can you upload a short video?

Rows can be expanded/collapsed by a single click. Are there any errors on the terminal output? You can run the applcaiton by using the following command (for Flatpak version): flatpak run io.github.hakandundar34coding.system-monitoring-center

[AlexFolland]

Peek 2023-08-06 11-53.webm

[AlexFolland]

I also tried from the CLI. I saw no particular errors when expanding or collapsing entries failed. I did see an error as shown below, but it seemed unrelated, since it did not appear when trying to expand or collapse an entry.

[alex@alex-pc ~]$ flatpak run io.github.hakandundar34coding.system-monitoring-center

(python3:2): Gtk-CRITICAL **: 12:06:58.167: gtk_css_node_insert_after: assertion 'previous_sibling == NULL || previous_sibling->parent == parent' failed

[hakandundar34coding]

The error in your comment is a GTK bug. It is fixed in GTK 4.10.5 but is is not in Flatpak repository yet.

Expanding/collapsing behaviors are controlled by GTK. I did not write code for this.

• What is your CPU model?
• Is your system under heavy load? From the video, it looks like the load is not very small. But I do not know the whole CPU usage.
• How many processes do you have?
• What is the update interval value? You can check it from General Settings window.
• Is the SMC GUI responsive (not only Processes tab)?

[AlexFolland]

• I am using an Intel i7 6700K at 4 GHz.
• The only significant processing is peek, which I'm using in the video to record the video. It's a convenient tool for recording a part of the screen. Otherwise, I just have background programs running; nothing doing significant processing.
  • This also happens when not recording with peek.
• At this time while responding, I have 480 processes running.
• The update interval value is 1 second, the same as Process Explorer which I used on Windows and ksysguard on Linux, both on the same system.
• Compared to Process Explorer and ksysguard, the SMC GUI is much less responsive. This is the only place where the input is totally ignored though. In other places, like when clicking the "Processes" tab, it can take several frames before the click registers, but it's not ignored entirely like on these arrows.

Ksysguard uses Qt. Maybe GTK4 isn't ready to be used for general purposes, since it causes input to be ignored. This kind of input ignoring makes me feel like there's something fundamentally wrong with how the GUI is programmed, even if that means it's on the side of GTK4. Even if it did take significant processing, clicking an arrow to expand entries should never be ignored.

Also, it's not like I have a million entries, such that a computer should have a hard time rendering the list. I have 480 processes running right now. A list with 480 entries could be handled easily even by computers in 2006, so I'm guessing there's some bloat applied by GTK4 or Python preventing this from working well. I could use Process Explorer which has a process list with a tree view without any input issues even back in 2006 with no significant processing issues even on my old computer which was before the release of the Intel i7 line of CPUs and which had 256 MiB of RAM.

[hakandundar34coding]

I tested the application when there is CPU load above 90%. The arrows worked. Update: The arrows worked when there is 100% CPU load.

Are there expanding/collapsing problems when all recursive columns are removed?

Can you reset Processes tab settings, list processes as tree and test the arrows again?

What is shown as CPU usage of SMC (in processes list) when you do not move the mouse arrow above the GUI for 3-5 seconds?

[AlexFolland]

To clarify the report, the arrows work, but intermittently. They ignore input if they are clicked during the lag spike probably caused by the sorting.

[hakandundar34coding]

To clarify the report, the arrows work, but intermittently.

I know it. I tried to learn does the same thing happen in the cases that are written in this comment.

Update: I tested the arrows when there are about 530 processes and 70% CPU load. CPU - Recursive column was shown. They worked. The GUI was less responsive in this test. All inputs for arrows are get by the GUI and expanding/collapsing operations are performed. System: Intel Core i7-2630QM mobile CPU, 12 GiB RAM, Intel HD3000 Integrated GPU.

There was no sorting operations when these arrows are used. I tested an alternative Linux system monitor. It was not very responsive too. Additionally, I tested XFCE system monitor. It was more responsive. But it is a simpler application.

You can wait 1-2 seconds if the GUI is not very responsive. It may trigger double click action even clicks are not very frequent. Accessing information processes from Flatpak sandbox requires more time. Additionally, there a lot of processes and one of the recursive options is enabled. And the programming language is Python. All of these cases require more CPU power/time to get system information. The GUI may be more responsive if you use non-Flatpak version of SMC. Some operations require about 2x-3x time when Flatpak version is used.

---

Do you use any antivirus applications that scans processes started by SMC? This may also increase time for getting process information.

[AlexFolland]

This is probably just a GTK4 issue. The expand/collapse arrows seem to throw away any mouse input made during the sorting operation (caused by the update which happens at each regular update interval), even if the arrow is in the same location in the list as it was before the update finished.

The easiest way to reproduce this is to just spam-click the arrow in the top-left (in my case, beside the systemd process). It expands and collapses without any issues between updates, but "during" the lag spike caused by the update, it ignores the click and doesn't even buffer it so that it affects the arrow after the update finishes.

I can even click the systemd arrow rhythmically at the same rate as the update interval to see several clicks in a row fail. Every time the update is happening, the click is discarded.

[AlexFolland]

Here's a video showing clicking the systemd arrow rhythmically at the same time as the update interval to see several clicks in a row fail. When it happens, the arrows changes color. When I stop doing it, the arrows stay the same color.

Peek 2023-08-08 12-46.webm

[hakandundar34coding]

I also faced the same problem today. It ignores clicks on the arrows if the sorting column is CPU or CPU - Recursive. Rows are changed when these columns are used for sorting.

[hakandundar34coding]

Expander arrows lose focus because of some reason. Expander arrow colors are darkened even mouse pointer is above them. They do not work. If mouse pointer is moved to another place and moved above the expander arrows their colors are lightened. They work in this situation.

Expander arrow behaviors of SMC v1 (GTK3) and SMC v2 (GTK4) are same.

But there is no similar expander arrow behavior on other system monitors that use GTK.

Update: This behavior (color) of SMC v2 (GTK4) is slightly different. Arrow colors are also lightened when clicked on them.

[hakandundar34coding]

The application is updated. There are minor improvements for expander arrows. I tested the updated application. They stopped working less frequently. It may be installable by using Flatpak in about 4 hours. The version number did not change. Can you check the behavior?

[AlexFolland]

I updated and tried the updated version. The behavior seemed identical to me. I was able to see the arrows ignore input consistently the same way as before.

[hakandundar34coding]

The arrows do not work if mouse clicks coincidence with process information collector function. This function completes its task in about 0.1-0.2 seconds depending on system performance and load. It would complete its task in a shorter time if it is not designed for both Flatpak and native installations. Fixing this problem requires splitting the application into two parts (foreground and background processes). But this increases complexity and requires some development time. Currently, there is no solution for this problem. I will think about more detailed code changes for a more responsive application GUI. You can increase the update interval to 1.25 or 1.5 seconds for less coincidence.

I will close this issue. But you can write additional comments. You can also open new issues for bugs, new features, etc.

[AlexFolland]

Is it impossible to simply read from the input event stream on each update and process any events which had been added since the last update? That's how input is supposed to work.

I'm a bit confused about the criteria for issue closure. In this case, you've admitted that the issue is able to be reproduced and you even know the cause, yet the issue is closed. Why not just leave it open so others can see that it is a known issue and potentially contribute a fix or test it again later with GUI toolkit updates?

[hakandundar34coding]

Did you mean that? Using signals/events for clicks on expander arrows and expanding/collapsing them manually (by using code). I will think about it.

About the issue closure: There was a plan for generating a file for known issues adding adding a link of it to the README file. This problem and its issue number would be added to the list of known issues. It will be added in about a short time. Also some GTK bugs (for example: popover menus may not be closed by mouse clicks outside them if dropdown lists used on them) will be added to it.

[AlexFolland]

Events should be used for all input. Ignoring input events while the GUI is not visually updating is ancient behavior from the 90s, in my opinion. We have the input event stream for that reason. If GTK 4 doesn't use it for clicks by default, GTK 4 is not a modern GUI tool kit.

As a game developer, I would not allow my game to ignore input and consider that acceptable for release. The same should apply to all software, in my opinion.

That all being said, if this is a GTK 4 issue specifically, the GTK 4 devs should solve it if they want their tool kit to be taken seriously. If it is theirs, it's still useful to keep this issue ticket open for testing feedback down the road and linking to the corresponding GTK 4 issue ticket if one is created.

[hakandundar34coding]

I saw some example codes for a bug report on GTK project repository some time ago. But they were found complex. This is a large application and much more complex than the example. I do not have plans for opening an issue for this problem.

Additionally, treeview widget that is used for SMC is deprecated. There is a newer widget (columnview). Its usage is recommended. But some features of columnview were added after GTK 4.8. Debian 12 repositories contain GTK 4.8. There are no plans for usage of this new widget.

I will think about reopening this issue and removing the file for known problems.