Add bindings for Details() download-size property

[joebonrichie]

Resolves #64.

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR adds a new public accessor method downloadSize() to the PackageKit::Details class. The method reads the "download-size" field from the underlying QVariantMap and returns it as qulonglong, paralleling the existing size() accessor pattern.

Changes

Download Size API Extension

Layer / File(s)	Summary
Public API Declaration src/details.h	The downloadSize() const accessor is declared in the Details public interface, returning qulonglong. The existing size() accessor remains unchanged.
Method Implementation src/details.cpp	The downloadSize() method is implemented to extract the "download-size" value from the QVariantMap and return it as qulonglong.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'Add bindings for Details() download-size property' directly matches the main change: adding a downloadSize() accessor to expose the download-size field.
Description check	✅ Passed	The description 'Resolves #64' is minimal but directly related to the changeset, referencing the linked issue that motivates these bindings.
Linked Issues check	✅ Passed	The PR successfully implements the core requirement from issue #64 by adding downloadSize() accessor methods in both header and implementation files to expose the download-size property.
Out of Scope Changes check	✅ Passed	All changes in this PR are directly scoped to implementing the download-size bindings requested in issue #64 with no extraneous modifications.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

• Generate code and open pull requests
• Plan features and break down work
• Investigate incidents and troubleshoot customer tickets together
• Automate recurring tasks and respond to alerts with triggers
• Summarize progress and report instantly

Built for teams:

• Shared memory across your entire org—no repeating context
• Per-thread sandboxes to safely plan and execute work
• Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/details.cpp`:
- Around line 70-73: The current PackageKit::Details::downloadSize() returns 0
for both "unknown" and an actual zero-byte download because
value(QLatin1String("download-size")).toULongLong() returns 0 for a default
QVariant; add a companion predicate PackageKit::Details::hasDownloadSize()
(declare in details.h and define in details.cpp) that checks the underlying
QVariant for the "download-size" key using
value(QLatin1String("download-size")).isValid() &&
value(QLatin1String("download-size")).canConvert<qulonglong>() (or equivalent
checks for non-null/convertibility), and update callers to call
hasDownloadSize() before using downloadSize().

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 74d0f681-5180-4571-a52a-314c31147005

📥 Commits

Reviewing files that changed from the base of the PR and between e16c22c and 9ab0206.

📒 Files selected for processing (2)

• src/details.cpp
• src/details.h

[coderabbitai]

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

0 is ambiguous: it means both "unknown/unsupported" and "zero bytes to download".

When a backend does not implement pk_backend_job_details_full(), value("download-size") returns a default QVariant and toULongLong() returns 0 — the same value returned for a legitimately zero-byte download. Issue #64 explicitly calls this out as something that must be handled.

The existing size() has the same design, so changing the return type is a bigger API decision; but at minimum consider a companion predicate:

💡 Suggested companion accessor

In details.h:

 qulonglong downloadSize() const;
+bool hasDownloadSize() const;

In details.cpp:

+bool PackageKit::Details::hasDownloadSize() const
+{
+    return contains(QLatin1String("download-size"));
+}

Callers can then do:

if (details.hasDownloadSize())
    showDownloadSize(details.downloadSize());

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/details.cpp` around lines 70 - 73, The current
PackageKit::Details::downloadSize() returns 0 for both "unknown" and an actual
zero-byte download because value(QLatin1String("download-size")).toULongLong()
returns 0 for a default QVariant; add a companion predicate
PackageKit::Details::hasDownloadSize() (declare in details.h and define in
details.cpp) that checks the underlying QVariant for the "download-size" key
using value(QLatin1String("download-size")).isValid() &&
value(QLatin1String("download-size")).canConvert<qulonglong>() (or equivalent
checks for non-null/convertibility), and update callers to call
hasDownloadSize() before using downloadSize().

[ximion]

The rabbit has a point, but we should adjust the API in one go later, using std::optional when we can introduce an API break again. Thank you for the patch!