I’ll look into this, though I thought I’d first do a dbus version?
In the case of Fahrplan, I can swap out the class and just remove the threading. I’m not sure what the better solution is. On the one hand with a dbus call I can confirm in Fahrplan. On the other hand …
Would it be possible to add library paths to circumvent this? Just a thought.
Setting “qmake system() behavior when parsing” to “Run” does not work in your case?
I think I just neglected qmake before build. Selecting ‘Run qmake’ did the trick. Thanks!
This is much nicer, thanks.
So, in order to see how it behaves I quickly broke out the calendar wrapper in an SFOS only version using the DesktopService. SFOS4 branch as of: Added a parallel calendar class for sfos only which does not run in a · poetaster/fahrplan@d8d8471 · GitHub
EDIT: Release Preliminary Calendar Support release, SFSO4 only · poetaster/fahrplan · GitHub building on obs
This eliminates the thread, which is pointless in this context. This works really well.
I’m thinking of back-porting this solution so that the 3.x SFOS users can benefit from it. It’s not quite in the spirit of how fahrplan was built, but then, most of the alternatives it builds for are dead. Still, I’d like to support ubuntu touch and …
I believe this would get into harbour, once I’ve removed the excessive permissions.