fix: calculation memory on hardware and system monitor

[urmauur]

Describe Your Changes

This pull request updates the memory usage calculations in the Hardware and SystemMonitor components of the web application to ensure consistency and correctness. The changes primarily involve switching the representation of memory usage from "available memory" to "used memory" in the relevant components.

Updates to memory usage calculations:

• web-app/src/routes/settings/hardware.tsx: Modified the progress bar and percentage display to calculate memory usage as (used_memory / total_memory) instead of (available_memory / total_memory) for better alignment with standard conventions.

• web-app/src/routes/system-monitor.tsx: Updated the memory usage display to show "used memory" directly instead of "available memory" by changing the calculation to use systemUsage.used_memory.

Fixes Issues

• Closes bug: Memory section calculation inconsistency - Total RAM != Available RAM + Used RAM #5897
• Closes bug: Memory section displays incorrect information - free memory swapped with total #5896

Self Checklist

• Added relevant comments, esp in complex areas
• Updated docs (for bug fixes / features)
• Created issues for follow-up changes or refactoring needed

---

Important

Update memory usage calculations in Hardware and SystemMonitor to use 'used memory' instead of 'available memory', and add tests.

• Behavior:
  • Update memory usage calculation in hardware.tsx to use (used_memory / total_memory) instead of (available_memory / total_memory).
  • Change system-monitor.tsx to display used_memory directly.
• Tests:
  • Add hardware.test.tsx to test memory usage display and other hardware settings.
• Misc:
  • Closes issues bug: Memory section calculation inconsistency - Total RAM != Available RAM + Used RAM #5897 and bug: Memory section displays incorrect information - free memory swapped with total #5896.

^{This description was created by for 1b96362. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to c018bf8 in 2 minutes and 27 seconds. Click for details.

• Reviewed 43 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 2 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. web-app/src/routes/settings/hardware.tsx:296

• Draft comment:
  The progress bar now uses (total_memory - used_memory)/total_memory, which represents the available memory percentage. The PR description suggests switching to a used memory representation. If the intent is to show used memory %, this should be systemUsage.used_memory/hardwareData.total_memory.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment correctly identifies that the calculation was changed to show available memory instead of used memory. However, this appears to be an intentional change to match the "Available RAM" display above it. The code is consistent in showing available memory rather than used memory throughout this section. The comment assumes this is incorrect without strong evidence. I could be wrong about the intention - maybe the UI should consistently show used memory instead of available memory. The comment raises a valid point about consistency with the PR description. Without seeing the PR description or requirements, I cannot assume this change is incorrect. The code is internally consistent in showing available memory. The comment makes assumptions about correctness without strong evidence. The code appears internally consistent in its choice to display available rather than used memory.

2. web-app/src/routes/system-monitor.tsx:96

• Draft comment:
  The RAM card computes 'ramUsagePercentage' as available memory percentage while the 'usedRam' row shows used memory. This mix may confuse users; if the goal is to display used memory usage consistently, update the percentage calculation to systemUsage.used_memory/hardwareData.total_memory.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

Workflow ID: wflow_MBYcYohTB55wFymn

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[github-actions]

Barecheck - Code coverage report

Total: 38.65%

Your code coverage diff: 1.29% ▴

Uncovered files and lines

File	Lines
web-app/src/routes/system-monitor.tsx	2-13, 15-17, 19-21, 23-29, 31, 33, 35-36, 39-48, 50-51, 54-58, 61-66, 68-72, 75-77, 79-82, 84-94, 97-101, 103-110, 112, 114-151, 154-197, 200-215, 217-235, 237-239, 241-244, 246
web-app/src/routes/settings/hardware.tsx	64, 71, 83-86, 88-92, 95-97, 99-102, 104-108, 119-125, 132, 134-136, 138, 140-142, 144-151, 154-156, 159-166, 327, 329-334, 336, 356-358, 378

[louis-jan]

It would be great to have test added haha

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed 1b96362 in 1 minute and 51 seconds. Click for details.

• Reviewed 181 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 1 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. web-app/src/routes/settings/__tests__/hardware.test.tsx:106

• Draft comment:
  Directly setting global.IS_MACOS can lead to side effects; consider isolating platform behavior via dependency injection or mocks.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a test file where global state manipulation is common and accepted. The IS_MACOS flag is properly managed with beforeEach() cleanup. The tests are explicitly testing platform-specific behavior, so directly toggling this flag is reasonable. Using dependency injection here would add complexity without clear benefits. The comment raises a valid general principle about avoiding global state. Global state can make tests harder to maintain and debug. While global state can be problematic, in test files it's common and acceptable to manipulate globals, especially when testing platform-specific behavior. The code follows testing best practices by cleaning up in beforeEach(). The comment should be deleted. The current implementation is a standard testing pattern and the suggested changes would add unnecessary complexity.

Workflow ID: wflow_88J8qrcq7bpCkBAz

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}