You work on that and I’ll take a crack at syncing via caldav this week. I have two use cases, tasks and deck, but tasks first. I’ll use python to keep it loose.
1 Like
I really need my milestones on a completely bifurcated gantt chart 
2 Likes
Not to hijack this thread, but on the topic of TODO lists, prioritizing, and calendar sync I have come up with this concept of managing tasks:
Please ignore the app there for now, it is crap and its development has stalled, but I think the idea laid out in the README may have some merit.
If you think so too I’d love some feedback, contributions or even independent implementation of that “spec”.
Again, sorry for interjecting this here, but it seemed fitting to mention it at this point of the thread.
3 Likes
I’m progressing on implementing an KCalendarCore + mKCal backend. I’ll publish it soon also.
You’re proposing a Python implementation also, as far as I remember. So both solutions are orthogonal. Having it in Python is fine also. Particularly since KCalendarCore + mKCal won’t allow the application to be accepted in Harbour…
1 Like
Ah, ok. Well, I’ll step back for a minute. It seems like it would make more sense to pick up tasks that complement your work. You have much more experience with caldav work in any case! Let me know if there is something I could do.
I had also started debugging on: Tasks | OpenRepos.net — Community Repository System which is largely functional with a custom c++ caldav client. But have been in python land on other projects, hence the choice. In principal, I’d like to help where it makes the most sense to contribute but can’t always tell where that is
1 Like
Is it possible this is a request that we could make at a community meeting? My hack to enable calendar entries (xdg-open) for fahrplan is still a bit of a sore point for me, although it seems to work fine for users. Or is this too much to ask?
About Harbour allowance, here my personal opinion:
- the KCalendarCore API (backed upstream by KDE) is well stable and could be allowed,
- mKCal is still regurlarly changing, mainly internally, but also in term of API from time to time. Allowing it in Harbour in its present form would be a bad idea and would lock some wrongness in the API. I’m currently in the process to propose a largely new API (following API changes in KCalendarCore for KDE Framework 6). The new API, after a period of test may be more suited for Harbour allowance,
- I’m not sure Jolla will allow these two low-level libraries, maybe they will prefer to allow the nemo-qml-plugin-calendar one. Sadly, this one is also changing from time to time (I’ve recently completely removed the
recurrenceIdargument from a good half of the public functions…) which supports Harbour restriction for the moment.
But that’s a good question to ask. Why not profit of the API break that will arrive in the next release in these repos to polish what should still be polished for Harbour inclusion ?
1 Like
- KCalendarCore, check
- mKCal, check I gathered as much from irc
That’s usable now, or?
Yes, that sounds like an opportunity!
Interesting! And a very different approach; I’ll have to look at it more in depth some time!
1 Like
Awesome!
Oh, I didn’t even think of that… That’s actually too bad, because I’d really prefer if all my apps could be in Harbour… Isn’t there maybe some creative way around the restriction? Maybe by making the database optional :'D
(Without looking at your code: did you know about Qt.openUrlExternally(...)? It basically does the same thing but cleanly from QML.)
Absolutely! Let’s do that!
Because the model in Fahrplan has a bunch of html wrapped elements, it’s not possible to do this from QML cleanly. The original fahrplan/src/calendarthreadwrapper.cpp at master · poetaster/fahrplan · GitHub uses KCalendarCore and mKCal which I replaced with: fahrplan/src/calendar_sfos_wrapper.cpp at master · poetaster/fahrplan · GitHub for SFOS builds. It’s not ideal There is one advantage to this approach which is that the user can choose which client should handle the calendar data.
In any case, if @dcaliste has an implementation complete, we can build a harbour compatible method like the above which can be built as an alternative with build flags like in Fahrplan. One could do both. All the structural work to get caldav compliant data structures can also be reused, even if storage is not mKcal.
Heh, I suspect much work for @dcaliste . I haven’t even gotten to testing the nemo-qml-plugin-calendar.
Ah, I see… Isn’t that quite a lot of code to maintain that is actually duplicated? Would it be possible to build mKCal & friends together with the app, maybe even with static linking, so that it is Harbour compliant?
Maybe this can even be adapted from Fahrplan, then?
I’m just thinking out loud here, without having properly looked at any of the code yet 
Not really. I could have done something more terse and elegant. But when I got it working, which was mostly trying to understand string serialization (cough), I just moved on. At that point in the game, I generally don’t aim for aesthetics anymore and just let the compiler deal with it 
I was responding to user requests for a feature I don’t use. They seemed happy with the result and until they voice otherwise, I’ll assume it’s ‘done’.
I think that if @dcaliste does the usual superb job of wrapping what can be, it could serve as a base class which other things could inherit. But, who knows. In any case, I’ll happily try to build on what he comes up with. I still think a pythonic approach might serve you better, but, it would require some scaffolding that might be ‘redundant’.
Die Einstellung sollte ich dir etwas mehr nachmachen 
.
Yeah, makes sense. I’m looking forward to what @dcaliste comes up with :)! As you say, maybe it’s possible to build a Harbour compliant layer with Python etc. We’ll see…
1 Like