8000 qt: Expose markup conversion utils by ismailof · Pull Request #706 · ximion/appstream · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

qt: Expose markup conversion utils #706

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 14, 2025
Merged

Conversation

ismailof
Copy link
Contributor

Expose as_markup_covert() function and AsMarkUpKind enum, so Qt clients can use the description fields in other suitable formats, such as markdown or simple text

Expose `as_markup_covert()` function and `AsMarkUpKind` enum, so Qt
clients can use the description fields in other suitable formats,
such as markdown or simple text
@ximion
Copy link
Owner
ximion commented Apr 1, 2025

This looks good, but is there any better way to send the error back to the caller, rather than to dump it on the console as a sideeffect?

@ismailof
Copy link
Contributor Author
ismailof commented Apr 1, 2025

This looks good, but is there any better way to send the error back to the caller, rather than to dump it on the console as a sideeffect?

I've been trying to find some good way to do it, while keeping the API still convenient, leaning into an optional parameter, maybe a std::error_code.

But trying to understand which kind of errors can be produced, it seems the error parameter is not used at all in the original function:

as_markup_convert (const gchar *markup, AsMarkupKind to_kind, GError **error)
, so maybe it is not even necessary to track it here?

@ximion
Copy link
Owner
ximion commented Apr 1, 2025

The error parameter exists so we can add an error in future in case there are parsing errors that we want to handle, and can add them without breaking API. Clients now would likely simply show the error->message if any error was set, and not look for an error code to be on the safe side.

The most straightforward way to convey this would be to emit a C++ exception, but introducing an exception into a library that otherwise doesn't use them would be a bad idea and quite surprising for users of the library.

@ximion
Copy link
Owner
ximion commented Apr 14, 2025

That you for the patch! I will have a look if it's possible to use std::expected here for error handling, or whether that is a too steep requirement (GCC 12 supports it, which is the baseline for AppStream, so it might be fine).

@ximion ximion merged commit 7cbcd1c into ximion:main Apr 14, 2025
10 checks passed
@ismailof
Copy link
Contributor Author

I will have a look if it's possible to use std::expected here for error handling, or whether that is a too steep requirement (GCC 12 supports it, which is the baseline for AppStream, so it might be fine).

Thanks for merging! I struggled to find a good way to expose the error handling (idiomatic and convenient) but std::expected, which being c++23 seemed a high requirement. IIRC in Discover and KDE Frameworks we now generally depend on c++20

@ismailof ismailof deleted the qt-markup-convert branch April 14, 2025 12:24
@ximion
Copy link
Owner
ximion commented Apr 14, 2025

Yes, while I think std::expected is generally worth it, for just one function it is a very steep requirement increase. So I ultimately went with a different solution, that only needs C++20 :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0