| Summary: | Library shows error messages by itself and quits the application when it can not find its resource files | ||
|---|---|---|---|
| Product: | [Applications] KReport | Reporter: | jordi fita i mas <jfita> |
| Component: | general | Assignee: | Jarosław Staniek <staniek> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | 3.2.0 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
Yes I agree. I see a few things: 1. KReport can be used without QWidgets, in this case we may need to split to the core and the QWidget-based (like I did in KProperty). In this case any error message would be abstracted to allow passing it to a non-QWidget APIs. 2. KReport can be used without designing - just the renderer, in this case we may need to split to the rendering core and the rest. In this case any error message would be abstracted to allow passing it to a non-QWidget APIs or suppressing. 3. In the case 1 the icon resource would be needed if any icon from there is used by the non-QWidget app for any needs. If you ask for abstraction of messages, there is https://api.kde.org/frameworks/kcoreaddons/html/namespaceKMessage.html in KF5 but it's up to maintainers to use it or offer any abstraction. |
SUMMARY I am trying to use KReport from a QML application. That application fetches the report layouts from a PostgreSQL and just needs to print the report, thus it does not use any of the designer features — layouts are designed in an external application, Kexi for now — but, the first time i try to call KReportPreRenderer.setDocument, the library complains that it can not find the resources for its icons. The error is the following: > Could not open icon resource file "kreport_breeze.rcc". > Application will not start. Please check if it is properly installed. That, by itself, is a mild annoyance; the problem is that the library decides to popup a KMessageBox without giving any chance to the application to display that error in its usual way — using QML controls in this case. Worse still, after the KMessageBox it calls qFatal, effectively calling std::abort, and terminates the application. In my opinion, the library has not enough context to known whether the error is fatal or no — for instance, in my case it does not matter whether the icons are loaded — and should let the application handle the error. In the case of Kexi it might be OK to abort, but as a general library it may be not. This report is to see if you agree that the library should not behave like this and, if you do agree, start discussions for a different design. I do not have any proposal because it is a bit hard to reach the application from where the error occurs. It seems that it is in the constructor of KReportPluginManager, instantiated by KReportPluginManagerSingleton the first time someone — KReportPreRenderer in my case— tries to use the plugin. Short of with an exception, right now i do not see how i can receive the error message…. Do you have any thoughts on this? What is the usual error reporting mechanism for KDE libraries? Thank you. SOFTWARE/OS VERSIONS Linux/KDE Plasma: openSUSE 15.1 KDE Plasma Version: N/A KDE Frameworks Version: 5.69.0 Qt Version: 5.12.2