Currently, we always render a plain process list. We should draw a tree instead. The underlying Avalonia control supports it; it's just that I chose to not implement that in our data model among the first project features.

Suggested change: just add a ParentId field to a ProcessViewModel, and group them somehow on the UI side.

Currently, we rely on WMI events to list Windows processes. That API is good enough for most purposes, but it has a problem with consistency: if we only rely on process start/stop events, we may easily miss some processes.

Also, we don't show the processes started before the program startup.

I suggest that we consider using periodic requests to CreateToolhelp32Snapshot, or periodic WMI queries of the full process list.

CreateToolhelp32Snapshot has a downside that we won't be able to get the process' command line.

The latter I remember as being clunky, but this is yet to be checked :)

Also, if we migrate to WMI list queries instead of WMI events, we may easily miss some processes, and we don't want to miss any (we should properly register quick start+exit of a process, if possible).

At this moment, nothing will be rendered in the tree if we couldn't find the ExecutablePath. In such cases, the default icon should be displayed.

Several issues with the current column structure:

1. Icons are giant, and also seemingly not all are of square shape
2. Let's move the icon to the Name column (with a custom renderer or whatnot)
3. Let's make the Name column the one controlling th tree hierarchy

Essentially, I want it to look like in Process Hacker 2:

See the code near this line:

Also, look for the number of this issue in the project code base.

Any logger.Error in the app should be reported somewhere, and it should be possible to see the errors thrown.

We need to add text logging and allow the users to know where they are stored.

We have to start from somewhere, so I'd like to implement a very basic process tree on Windows and start using that daily, to see what other features to implement.

We should add process binary icons for Windows.

Currently, we don't have an icon. We should draw one.

SVG graphics are acceptable; I can organize converting to other formats on build.

Context

• Platform: Windows 11

Reproducing steps:

• Launch ProcessDoctor
• Press PrtSc
• Create an image of any size
• A popup message will appear (something like this):
  
• Click on the popup message. The preview window will be opened:
  
• In ProcessDoctor open wininit.exe, then services.exe. Find svchost.exe with the following parameters:
  
• Close the image preview window

Stack Trace

02:35:42.453 |E| ProcessDoctor.ViewModels.MainWindowViewModel | :17                           
 | System.InvalidOperationException: Call from invalid thread
   at Avalonia.Threading.Dispatcher.<VerifyAccess>g__ThrowVerifyAccess|16_0()
   at Avalonia.Controls.Primitives.TreeDataGridExpanderCell.set_ShowExpander(Boolean value) in /_/src/Avalonia.Controls.TreeDataGrid/Primitives/TreeDataGridExpanderCell.cs:line 50
   at Avalonia.Controls.Primitives.TreeDataGridExpanderCell.ModelPropertyChanged(Object sender, PropertyChangedEventArgs e) in /_/src/Avalonia.Controls.TreeDataGrid/Primitives/TreeDataGridExpanderCell.cs:line 138
   at Avalonia.Controls.Models.TreeDataGrid.HierarchicalRow`1.set_ShowExpander(Boolean value) in /_/src/Avalonia.Controls.TreeDataGrid/Models/TreeDataGrid/HierarchicalRow.cs:line 89
   at Avalonia.Controls.Models.TreeDataGrid.ShowExpanderObservable`1.OnCollectionChanged(Object sender, NotifyCollectionChangedEventArgs e) in /_/src/Avalonia.Controls.TreeDataGrid/Models/TreeDataGrid/ShowExpanderObservable.cs:line 87
   at System.Collections.ObjectModel.ObservableCollection`1.OnCollectionChanged(NotifyCollectionChangedEventArgs e)
   at System.Collections.ObjectModel.Collection`1.Remove(T item)
   at ProcessDoctor.ViewModels.ProcessTreeViewModel.OnProcessTerminated(SystemProcess process) in D:\C#\ProcessDoctor\ProcessDoctor\ViewModels\ProcessTreeViewModel.cs:line 116
   at ProcessDoctor.ViewModels.ProcessTreeViewModel.<>c__DisplayClass7_0.<.ctor>b__2() in D:\C#\ProcessDoctor\ProcessDoctor\ViewModels\ProcessTreeViewModel.cs:line 38
   at JetBrains.Diagnostics.LogEx.Catch(ILog log, Action action)

See the code near this line:

Currently, we hardcode these to always have 16×16, and the color scheme is weird. Should be improved.

We should add columns for the current process CPU/memory consumption. Optionally, support various memory metrics for Windows.

ProcessDoctor operates under condition of eventual process tree consistency, which means that for a short period of time, there could be some artifacts like processes with no parent (which will come afterwards), or two processes with the same id.

That could happen if the process enumeration is not done on the process list snapshot, but on a live process list, e.g.

1. Process with id = 42 starts.
2. We start to enumerate the processes and see the process.
3. Process with id = 42 terminates.
4. We proceed to enumerate the processes.
5. A new process gets started, and pid = 42 gets reused.
6. We still enumerate the processes and see the newly started process.

We should be able to properly deal with it somehow.

See TODO[#14] in the code.

Add support for macOS!

See the code near this line:

So, we know the executable of some app and want to get the corresponding AppInfo from GLib.

Currently, to do that, we enumerate all the available AppInfo objects and just pick the first one with the corresponding Executable field.

Maybe we could improve this? How is it supposed to really work? Can a single executable have several AppInfo entries?

Add support for Linux!

Currently, we rely on a plain list ObservableCollection<ProcessModel> Processes model.

This is problematic in some ways.

1. It's unclear how to efficiently find the process whenever we decide to delete it.
2. It is unclear how to produce the tree structure from them.

Currently, I am thinking about declaring some sort of observable dictionary (is there such a class in BCL? if not, we could create our own).

Make sure to review and eliminate every instance of TODO[#5] in the application code.

See the code near this line:

Currently, it's impossible to write tests for this function's behavior. We should update the code to make it testable.