System Monitor

Software is complete! I added disk information since that was something I mentioned in the earlier dev logs. I had claude code help me out with the CI/CD and cleaning up the code base a bit to ensure everything is ready for a v0.1.0 release. I also wrote the README, and sorted out the licensing requirements since I’m using Qt and therefore need to follow their software licensing.

I cleaned up the UI. I feel the borders were simply clutter which made the UI harder to go through, so I swapped it to simple dividers. I also refactored the cpu module in a similar manner as to how I refactored the memory module earlier. Current miqt is broken due to QT6.11 so I swapped to a fork which is working, will swap back to the original when it starts working again.

Been a good bit since I worked on system monitor. After coming back I decided to refactor the entire memory module since I felt it could be simplified, and I did! It went from 4 files to 3 files, with better naming and way cleaner code. Essentially I moved functionality out of cross-platform files and moved it into darwin.go, so now UI is generated by a file which has proper context to it’s platform. No changes to the UI or functionality at all though, so not much to show.

I ended up not making a custom graph widget because it would be really, really annoying to do so. But I did manage to clean up the graph to look just a bit better in my opinion, so I don’t have any issues with the built in graph widget anymore. Similarly I made the design for the memory breakdown a bit more clear by indenting some of the information when required

I also created an alternative graph which actually uses the platform specific data on MacOS to show a breakdown of memory used (App Memory, Compressed Memory and Wired Memory). It looks quite nice in my opinion. I do need to make some things more explicit in the UI by default though, like what the graphs represent and the unit on the Y-axis. I’m going to leave that for later though, since I want to get back to getting more system information. This time I’ll probably go for storage device information.

Creating the Memory UI was relatively smooth, seeing as a lot of it was just CPU UI code reused and changed a bit. Making the UI update when memory values change was also surprisingly easy due to go routines. I also made some visual tweaks to the CPU UI to make it look just a bit cleaner.

I’m going to change the graph eventually because QT Charts makes it really annoying to do what I want to do. This means I’ll have to make my own graph UI component, which shouldn’t be too hard (hopefully)

I made quite a lot of changes this time, so I’m going to split them into points so it’s a bit easier to read.

1. I refactored quite a bit of code into separate files, this means that one off pieces of code which are reused frequently or platform specific code have now been separated into different files. An example is cpu/cpu_info.go which has been split into cpu/info.go and cpu/info_darwin.go depending on if the code is useful everywhere, or only on MacOS (Note that the cpu_ prefix is gone).

2. I introduced a few utilities which are probably going to be used a lot, one of which is conversion from Bytes to different formats up till Yottabytes, which is 10^15 GB. The other one is a simple wrapper for value unit pairs since it keeps code clean in info types like the one in memory/info.go

3. I finally got around to adding a different type of system information, this time being Memory (RAM) info. Since not all info is relevant/existent on all platforms I created an interface called PlatformInfo, which can be implemented by different types to create unique info per platform as seen in memory/info_darwin.go T

The part I’m the most proud of is probably memory pressure, simply because I’ve not seen any information on the internet documenting what the boundaries for the different levels of memory pressure are (The colors on the memory pressure graph in activity monitor). It turns out it’s based on “System-wide memory free percentage” as seen when running the memory_pressure command. This value isn’t literally how much RAM is free but is based on other statistics which I can’t quite figure out.

Now I have to actually render all this information on screen. I quite like the way which Activity Monitor does it on MacOS so I’m going to go for something similar.

I finally got the CPU info display looking pretty solid, landing on the horizontal grid for the core/cache info took longer than I would like to admit. I also can’t think of any other relevant CPU info which is available on MacOS, so I guess it’ll stay like this for now until I decide to revisit it.

Since CPU info is done, I’m going to implement some other type of info like GPU info, Memory info or Storage info, but I haven’t quite decided which I want to work on at the moment.

I ended up splitting existing code into different folders to isolate different functionality, with the general idea that UI should be separate from information fetching, and that each section should get it’s on folder.

I also deleted the glow_image widget since I realized it would be way better to have a generic container widget which draws a border around children, since borders are a really important part of the UI to separate content explicitly.

There’s now a lot more CPU info being fetched, including core types (performance/efficiency), CPU cache information, and CPU code names. The UI has gotten to a point where I find it tolerable, but it still feels a bit off to me so I’m going to try different spacing between all the elements to see if I can get it to look better.

Displaying the CPU info was pretty annoying, mainly because the way I implemented my GlowImage widget broke the border as soon as it was in a layout. I was able to fix it after using contents margin to declare that some space in the widget is used for decorations (the border), and in the process created some debug tools which will probably be useful for as long as I work on this.

I also took way too long to center everything vertically and horizontally, mainly because I didn’t realize that BoxLayouts like to use all the space if you don’t add stretch explicitly. Displaying the actual info on screen was relatively easy since I could just use QLabels in a VBoxLayout.

Next up is probably some styling to make the UI a bit better looking, along with fetching some more CPU info to display.

So it’s my first time working with either Go or Qt so it’ll be a slow start to the progress logs I’m sure. Right now i want to focus on getting a decent looking UI, along with some static system information. I’ve implemented a bit of code which fetches basic CPU information on MacOS, and I’ve also created a custom widget which creates an image with a border around it.

Next up is probably to display the CPU info I fetched, along with other stuff like memory and storage configuration.