September 27-30 - Sailathon 24 in Prague

General
#60

Another idea proposed by vlagged:

#61

Great community response! We’ve collected 270 Euro for the Sailathon 24! Thanks!

4 Likes
#62

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 :wink:

2 Likes
#63

I heard there are two Taak devs present in Prague anyway. :eyes:

1 Like
#64

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.

6 Likes
#65

I would re-phrase that, I think I’d like to use an existing technology for tasks/todo: CalDAV :slight_smile:

  • A native Todo app. As I was looking up what to use for KDE and found a Todoist client just like @direc85 suggested in this thread: Native Todoist app? However, since then I found that 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.
    • Bonus points: re-use the existing calendar account
    • integrate with browser as “read later”:-P
4 Likes
#66

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

2 Likes
#67

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).

5 Likes
#68

You mean GitHub - dcaliste/buteo-sync-plugin-webcal ?

#69

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.

4 Likes
#70

@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.

1 Like
#71

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 :slight_smile:

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?

2 Likes
#72

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…

3 Likes
#73

why not yottagram?

Sorry to butt in but the official short name is yotti, sounds cuter than yotta :stuck_out_tongue:

5 Likes
#74

Offtopic: i use yottagram only for sending multiple pictures and for voicecalls. Those are really nicely implemented features.

2 Likes
#75

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!

2 Likes
#76

in my opinion Fernschreiber also has a very nice clean look, but I don’t use Telegram anyways

#77

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 :slight_smile: 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 :slight_smile:

2 Likes
#78

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:

  • you need a memory representation that is suited for QML:
    • KCalendarCore is a Qt oriented representation of object described in the CalDAV RFC and its extensions. It exposes events, todos and journals as QGadgets. They are gathered in Calendar QObjects. The project has a long inheritence and is well supported by KDE, being part of their Frameworks. It is using state of the art Qt. Sailfish OS proposes it over Qt 5.6.
    • QtOrganizer from QtPim is another Qt oriented representation of events and todos. It is slightly less 1:1 with CalDAV RFC objects but not far. It seems to me that QtPim is advancing slowly maybe even stalled. It is still part of the Qt project though and has been ported to Qt6. Sailfish OS offers it as a backport to Qt 5.6.
  • you need a backend to store the data on disk for off-line usage:
    • KDE is using Akonadi, not available on Sailfish OS.
    • mKCal is an SQlite backend, available on Sailfish OS. It was part of KCal before its division into KCalCore (becoming later KCalendarCore) and mKCal. It is inheriting all the history of KCal and thus suffers from some old decisions on its API. It’s only used by Sailfish OS at the monent. It is currently not compatible with latest KCalendarCore from KDE Framework 6, but I’m working on it ; -) It is not yet ready as a backend for QtOrganizer, but it may become ready in the near future.
  • you may want a synchronisation with on-line services:
    • Buteo framework is doing so on Sailfish OS. 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).
  • you may need some account credentials for the on-line service:
    • Single Sign On (sso) framework is handling the authentication, being password or OAuth2. In relation with 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 !

7 Likes
#79

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 :slight_smile:

1 Like