Nemo-qml-plugin-calendar timeline for harbour?

Applications
#21

Got it, thanks! I’ll see if I can make it compile!

#22

I manged to get it to build. The includes get flagged as not found and auto-completion doesn’t work, but that’s for @martyone I think?

In any case, it doesn’t run but segfaults immediately. But it does compile!

Thanks for the help!

#23

I’ve just tried to compile your SFOS4 branch and run it on device. I didn’t get any segfault. I tried to look for a journey between two cities in France using Bahn.de and it provided correct results.

Anyway, if you have any further questions on the calendar stack, don’t hesitate.

#24

Ok, it’s probably my test device then. I have a second devie, So, here goes!

Thanks a bunch!

#25

Thinking about it, the best way to add an event to the calendar, would be to talk to com.jolla.calendar.ui DBus address.

The idea would be to serialise your data into ICS (and you can keep your KCalendarCore code to do it), and pass this data to DBus.

Code to get ICS data :

KCalendarCore::Event::Ptr event( new KCalendarCore::Event() );
event->setSummary(calendarEntryTitle);
event->setDescription(calendarEntryDesc);
event->setDtStart( m_result->departureDateTime() );
event->setDtEnd( m_result->arrivalDateTime() );
KCalendarCore::ICalFormat format;
QString icsData = format.toICalString(event);

And you can drop all mKCal code.

For DBus, it’s :

  • service: com.jolla.calendar.ui,
  • path: /com/jolla/calendar/ui,
  • method: com.jolla.calendar.ui.importIcsData(icsString).

Like that, it will push the calendar application and open the import dialog letting the user choose the calendar where to import, or discard.

You still need the Calendar permissions to talk to this DBus interface, but at least it has more chance to be allowed once in Harbour than fiddling with mKCal directly (where you can erase all the calendar database in two lines of code). At least, that’s my point of view.

#26

That’s about what I was hoping would be the consequence of using the qml plugin, although still more direct. In any case, being able to not touch the storage directly would be a ‘good thing’ ™.

So, for the SFOS4 branch, I’ll try to go the dbus direction!

It seems the segfault was, probably, related to that device being 4.3. You are, I would hazard a guess running 4.4?

#27

Well, the QML bindings offer more or less the same full access to the calendar database than mKCal. I don’t think it will be allowed easily in harbour (personal opinion).

That being said, I’m even wondering if we could argue to let the DBus import method opened for everyone, without permission. Actually, this is not a security break for the calendar database and there is a clear dialog to accept or not the import. I’ll try to add this to the discussion on Thursday. Or even propose a PR in sailjail-permissions to see what could be the feedback…

About the segfault, I’m running 4.4, indeed. Compiling for 4.4 but running on 4.3 maybe adventurous. The ABI is not guaranteed between releases in the calendar stack. I’ve already troubles to refrain myself from breaking the API every release ; )

#28

Ah. I misunderstood this.

Which I was about to implement with:
QDesktopServices::openUrl(QUrl("file://" ahem :slight_smile:

Ok, I’ll be there on Thursday morning and try not to confuse the issue. I think you’re spot on with the DBus import method being a safe and responsible way forward.

Thanks!

#29

Perfect also. This will rely on xdg-open that will eventually call the appropriate DBus method, see from /usr/share/applications/jolla-calendar.desktop :

X-Maemo-Service=com.jolla.calendar.ui
X-Maemo-Object-Path=/com/jolla/calendar/ui
X-Maemo-Method=com.jolla.calendar.ui.openUrl

openUrl() with one argument will call importFile() which is equivalent to the mentioned importIcs() but reading from a file instead of reading from DBus arguments. Pay attention that the method will return immediately, but the file will be read on acceptence of the dialog which may create some issues with the life of the temporary file…

#30

I wonder if this is ‘preferable’ if it passes the harbour test? I think it might be allowed?

#31

Good point. The QDesktopServices way should be allowed in Harbour. Which is another argument to allow the DBus import for everyone ; )

(but I would understand rejection for the DBus import based on the (in-)stability of the DBus API in Jolla calendar application)

#32

I’ve seen you have troubles also on a 4.4 device. Could you run it inside gdb ? I’m curious to see what could segfault in the code changes that have been done.

#33

I’m going to ping piggz first before going down that road. There are two other, probably unrelated, problems with the port. One is droidmedia (video recording KO) and one dbus / lipstick related (screenshots KO).

I’m also working on fixing memory leaks, so I’ll have to go that route soon enough, but I’m trying to stave off confusion :slight_smile:

#34

Found it. main.cpp

83            setuid(getpwnam("nemo")->pw_uid);
84           setgid(getgrnam("privileged")->gr_gid);

Ah, the gory glories of old code :slight_smile:

It runs fine if those lines are commented out, but, of course:

[W] unknown:0 - Unable to create calendar database directory: "/home/defaultuser/.local/share/system/privileged/Calendar/mkcal"

EDIT: And, just cause, setting it explicitly to “defaultuser” gets:

[W] unknown:0 - Unable to create calendar database directory: "/home/defaultuser/.local/share/system/privileged/Calendar/mkcal"
[W] unknown:0 - sqlite3_open error: 14 on database "/home/defaultuser/.local/share/system/privileged/Calendar/mkcal/db"
#35

I took a crack at this last night in my SFOS4 branch. It does get to the import window, but fails. I used
QStandardPaths::writableLocation(QStandardPaths::CacheLocation) for location which might be the issue. But…

I noticed ff I open the file (in filebrowser) it open up the import window with a chooser (defaults to none?) for Calendar. After choosing a Calendar import succeeds.

QDesktopServices::openUrl( QUrl("file://" + tmpFile->fileName(), QUrl::TolerantMode))

Was the call. There is another issue, since this runs in a thread, it may be that dbus is necessary to release the temp file in an orderly fashion.

#36

If you are in the jail, I’m afraid the cache directory is not visible.

#37

Ok, I’ll try writing to Documents and see if that works. It does make sense that you would only see the selection for Calendar if the file is actually readable. It was a bit late last night.

EDIT: DocumentsLocation works. Now the threads issue. Thanks!

#38

For the current implementation not succeeding creating the DB, I’m wondering if you gave the Calendar permission to Fahrplan ? It would give access to the DB, even without playing with the UID and GID, see https://github.com/dcaliste/harbour-logbook (get Calendar permissions from Desktop file).

#39

This might be the known issue with PKGCONFIG - see Known Issues | Sailfish OS Documentation.

#40

Couple remarks from my side:

  • Better use QUrl::fromLocalFile() rather than constructing file:// url as that can get broken with url escape rules on some cases. Might not apply here, but good to avoid that as convention.
  • The openUrl() doesn’t actually use xdg-open but the request goes over wayland. Which is better since it allows to open the app selection dialog in case multiple apps are registerd for the file type.
  • The temporary file is a good question, need to figure out something.