Note: Taskwarrior and Todoist are very different platforms and they won’t be able to share code.
Todoist doesn’t have a SFOS-native UI at the moment ao that would have to start from zero. For Taskwarrior there’s Taak already, that could be nudged forward too 
I heard there are two Taak devs present in Prague anyway. 
Voice- and especially videocalls would be extremely great and fill a big gap on SFOS in my opinion, but since I can’t contribute anything myself, this is just an unqualified interjection from the sidelines.
I would re-phrase that, I think I’d like to use an existing technology for tasks/todo: CalDAV 
mailbox.org and KOrganizer can save Tasks into CalDav (presumably) and should also be visible in Thunderbird. This is why I am now thinking to add a Todo feature based on caldav to SailfishOS. More like tasks.org.
:-P
I also had a thought along these lines. I was thinking of next cloud integration, explicitly. It’s a great idea to piggy back on the calendar account. To this purpose, I had started working on Tasks | OpenRepos.net — Community Repository System I got stalled last year …
Edit: I just saw that @Thaodan had put some work in at SailfishOS-Mirrors/harbour-tasks - harbour-tasks - Gitea: Git with a cup of tea
Bonus points: re-use the existing calendar account
I may add also that CalDAV Buteo sync plugin should be able to synchronize todos out of the box, after some testing of course…
About KOrganizer, I’m currently rewriting the mKCal plugin for QtPim (and thus QtOrganizer classes), see GitHub - dcaliste/qtorganizer-mkcal as it could be later used by UBPorts. They are currently planning to switch away from evolution server for the backend of calendar events. They may switch to use mKCal and Buteo, depending how large the changes are and how correctly the new backend would work well or not with their UI. SailfishOS itself is not using QtOrganizer but if you plan to use it for a project, it could once again have a mKCal backend and thus integrate properly with calendar events in SailfishOS.
During the time of QtMobility, QtOrganizer had a mKCal backend, but it has not been updated as far as I know since the switch to Qt5 (and Qt6). QtOrganizer and mKCal has changed their API since QtMobility and I prefered to recode the plugin from scratch than update the old one from QtMobility.
Edit : as usual, I mis-read Korganizer and QOrganizer… Well, I guess KOrganizer is directly based on KCalendarCore and not QtOrganizer… Anyway, nice move to add todos via CalDAV, either based on KCalendarCore (used in Sailfish OS) or QtOrganizer (with potentially a shared backend with Sailfish OS).
No, actually the official one : GitHub - sailfishos/buteo-sync-plugin-caldav
Currently, it is filtering out the todos in the request. But one can add todos in the request to.
@jauri.gagarin.II for sure you hit the nail with this. Voice and even better video calling is really something to look forward into the future of SFOS native apps like Whisperfish & Fernschreiber! I think if this goal could be achieved, there is a potential to reduce power consumption in video calls that is with Signal & Telegram Android apps currently not possible. I’ve noticed a huge current drain of more than 1A when camera & audio is on in those Android apps. Of course this depends if the user calls via Wifi or in 4G network.
I had a recent conversation with @Mister_Magister and thought, well, there is voice call support in yottagram … so there may be some joint efforts at least where Fernschreiber is concerned. Though, you can just use Yotta … I kinda like Fernschreiber because of the name
As I understand it, voice and video are in the works from @rubdos and @direc85 ?
Is the scope of either of these efforts within a 4 day hackathon?
I kind of expect that most of the power usage goes into the video encoder. For voice calls however, should be pretty much fine!
Yes!
I’m honestly not sure yet. There will be UI work, integration work with Telepathy (I want to pick up calls with my hands-free!), and the whole call state management system that’s specific to Signal or Telegram. And of course, the whole multimedia pipeline will be very interesting too…
I’m trying to prepare as much Signal-specific code by the time I get to Prague, but it’s rather difficult to guage how much work it will still be…
why not yottagram?
Sorry to butt in but the official short name is yotti, sounds cuter than yotta 
Offtopic: i use yottagram only for sending multiple pictures and for voicecalls. Those are really nicely implemented features.
Thank you very much for your reply @dcaliste, appreciated!
If I read that right “based on (…) QtOrganizer (with potentially a shared backend with Sailfish OS).” is the way to share an existing account?
Or, to put it in another way: what would your preference be, if you would be the one working on this? What route would you take? Thanks again!
in my opinion Fernschreiber also has a very nice clean look, but I don’t use Telegram anyways
I think that’s why I chose Fernschreiber, something like less ‘bubble space’, but I have to admit, I wanted to compare again since some people try to voice call me But, I also don’t have chat clients or social media clients running all the time. I only turn them on once a day and off again
I don’t want to impose my opinion on the matter. So let’s start with some general information related to calendar handling starting from the application point of view:
buteo-sync-plugin-caldav is doing the job on Sailfish OS, updating any storage using an mKCal backend (well almost any, currently it’s hardcoded for the system storage, but it may be amended easily to do it on any file).libaccounts-qt, it allow to setup and use an account for an on-line service. It is used internally by the buteo-sync-plugin-caldav to get the necessary credentials.Now that the technical points have been listed, let’s move to my personal opinion on the matter. The technical choices to develop a todo application depends, in my opinion, on the code you may want to reuse. If like for UBPorts case, you already have a UI that is using a framework, it’s better to stick with this framework and try to put mKCal as a backend. If you don’t have a UI ready, I would go myself for KCalendarCore as a memory representation since it’s well maintained and not too badly documented. Using mKCal as a backend as some pros, like being able to rely on the synchronisation framework, and some cons like the fact that its API is not completely future proof at the moment (but migration will be simple and I can do it via a PR once mKCal moves to support state of the art KCalendarCore). mKCal itself is not threaded and requests are synchronous. This can add some nasty lags of some hundreds of milliseconds for large requests like getting recurring todos. Sailfish OS is circumventing this with nemo-qml-plugin-calendar which is adding a background worker to database IOs. But it is not very well suited in our case since it is event oriented. There is no todo support there. Todos could be added, but it’s a medium to large task in my opinion.
In any cases, the current status of the stack in Sailfish OS, is only dealing with system calendar. So adding todos will require some adjustments in the Buteo plugin for instance.
As an example, I worked some years ago for @ichthyosaurus todo application, to propose a draft on switching from a homemade backend to a mKCal one, see GitHub - dcaliste/harbour-todolist at mkcal It can give a quick view on how to use mKCal directly and expose it QML (here using the API of the objects developped for the application).
Too bad I cannot come to Prague, I would have been delighted to speak about Pim, calendars and todos !
Although I have some superficial knowledge (ex. Calendar Integration in Fahrplan), I have to admit to thinking a short term goal with a very limited scope might make sense first.
That is, not deal with a local backend, at all. Just fetch caldav and push caldav. Usually, I’m averse to ‘online only’ apps, but for Calendars and todos, I’ve beome dependent on sync across devices. But, big but, I don’t have huge Calendars or to-do lists (those are on github/gitlab) …
Just a thought, though in the long run doing some KCalendarCore might be the right way to go
@pherjung et al - as the “call for papers” approaches the deadline, I was thinking that we could have at least one poll with all ideas gathered for “popular vote” at that time.
A second one could be made for sign-ups (multiple allowed) for participants.
This second one could actually be done in a separate IM discussion - that may mean also deciding the instant messaging platform, which is always a challenge. Maybe IRC would be best as #sailfishos-hackathon or something, and it allows joining from Matrix too. Alternatives could be Matrix only, or Telegram or Signal. Any other native clients I’m missing? (No actual native poll support needed for this).
(L.E. I missed XMPP of course. Also: I have access to all of the above.)
As the case of “doable goal” was mentioned, I think one pre-requisite is to have more than one person for projects tackled without previous experience (of course anyone can hack anything if they’re in “the zone” already;)
Thoughts?
The topics posted so far are all very technical. What do you think about discussions on non-technical aspects, like the community, UI, documentation, marketing, the grand scheme and broader picture, user support etc?