Builds, but not specifically tested
Details
Diff Detail
- Repository
- R205 KAlarm
- Branch
- Applications/19.08
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 14664 Build 14682: arc lint + arc unit
Tested on Neon.
The patched code doesn't start KOrganizer either. The QDBusInterface iface(KORG_DBUS_SERVICE, QStringLiteral(KORG_DBUS_LOAD_PATH), ...) call returns the error "The name org.kde.korganizer was not provided by any .service files".
Substituting with QDBusConnection::sessionBus().interface()->startService("org.kde.korganizer") returns the same error.
It also turns out that the original code didn't work - the KDBusServiceStarter::findServiceFor() call returns the error "Cannot open library libkdeinit5_korganizer".
Note that KOrganizer is installed, and if it is already running, the code works, and qdbusviewer lists org.kde.korganizer.
src/functions.cpp | ||
---|---|---|
1848 | Please leave formatting unchanged. |
You need to update korganizer in order to grab this recent commit: https://cgit.kde.org/korganizer.git/commit/?id=80a7965ae6a22628c08a2db6c7cc6c913a48605f
This is what makes DBus activation possible.
src/functions.cpp | ||
---|---|---|
1848 | The && condition on the second line being aligned with if and not with the first condition (!reply..., was on purpose? Quite unusual, but OK, your call. |
After updating korganizer, it now starts korganizer successfully. However, if korganizer is then quit, it fails on subsequent attempts to start korganizer, when it executes
QDBusInterface iface(KORG_DBUS_SERVICE, QStringLiteral(KORG_DBUS_LOAD_PATH), QStringLiteral("org.kde.PIMUniqueApplication"));
In this case, iface.isValid() returns false, but iface.lastError().message() returns an empty string.
Thanks for the test!
That's a pre-existing problem coming from the global variable "korgInterface". I'll remove that variable and create the DBus interface every time instead.
I tested the new patch, but exactly the same error still occurs after quitting KOrganizer and trying to start it again.
Weird.
Can you guide me though using kalarm in order to test this? i.e. please describe exactly the steps you are taking.
The steps which I used to test it were:
- Enable KAlarm output in kdebugsettings (you'll need to see debug output to know exactly what's going wrong).
- Quit/kill KOrganizer if it's already running.
- Run KAlarm from a terminal.
- In menu bar, choose New -> Display Alarm.
- In the New Display Alarm dialog, type some random text in the big text box, select a time enough in the future so that the alarm won't expire while you're testing it, and select "Show in KOrganizer" (you may need to click the "More Options >>" button to see this option.)
- Click OK.
- KOrganizer should now start up, and the event should be visible in it for the selected date.
- In KOrganizer, select File -> Quit.
- In KAlarm, click on the alarm which you created, in order to edit it.
- In the Edit Display Alarm dialog, change the text in order to enable the OK button again. Click OK.
- KOrganizer should start again, but in my testing, I just got an error message. See the debug output for details - the user message is not very specific.
Thanks. Reproduced, and fixed. It turns out that just creating a QDBusInterface and calling isValid() does not autostart the service. Making the actual call does.
This is no bug. isValid() doesn't make a remote procedure call to check if the remote object still exists.
It is documented as " It returns false if there was an error during the creation of this interface ". Emphasis on CREATION.
If it did make a remote call, it would be slow, and still not 100% safe (the remote app could exit between isValid() and the actual call we want to make. So we might as well just make the call and see if it worked.