Well, I think I found the reason for this, or at least a reason introduced in 3.4.0. To avoid alarms ringing for disabled calendars (in the sense of accounts) as it happened previously, we linked the alarm to the visibility of the calendar only. And we setup a binding between account status and visibility. This binding is supposed to be triggered on every status change of the account, but it’s actually not the case. It is firing every time a setting is changed in the account… I need to discuss with @flypig of this, maybe tomorrow if he has time on IRC #SailfishOS channel.
2 Likes
That sounds good; I’ll follow along with your discussions with Chris until the topic comes up.
1 Like
Cleared calendar db and contacts and removed the account just to see if it helps. Still having this issue. Calendars re-selected to visible after just setting them to not be visible. As in the screencap from apozaf.
@apozaf has raised this as a topic for the Community meeting on Thursday, so hopefully there’ll be an answer for then (or at least, some discussion on the topic).
1 Like
Same here. Nothing changed that stange behaviour on 4
Darn. We need to investigate this more.
Checked this as I updated to 4.2. Yeah its still an issue that google calendars reappear as visible even though selected as not visible from manage calendars pulley item. I have a lot of organization calendars that are shared to me and I would want to disable them on my phone to see my events.
I cannot reproduce. Is it happening at every sync ?
I think it’s when loosing connection or switching to airplane mode. But not always. hmmm.
Definately after every restart.
I’m sorry, it’s not clear for me how to reproduce.
Looking at the code, one action that definitely triggers the visibility issue:
- go to the setting panel for your Google account and enable or disable calendar sync or contact sync for instance and swipe back to the list of accounts.
I still cannot see in the sync code how it can happen during a scheduled sync though : /
If @miqu or @apozaf can provide some steps on how to reproduce, it would be of great help to find a solution. Any other information are good to take also.
1 Like
Hi I was checking when I installed 4.2. And it occurred right in front of my eyes when I had unticked the calendars and came back to view it.
A few days ago I tested again and it didnt occur right away, but in a few hours without my interactions, it had reset the calendar view.
From the screeshots times we can see that it occurred between 16:37 and 20:20 so in under 4 hours.
Is it storing the calendar view settings right away or on app closing? Could it be that Oom or smth kills the view and the settings are not stored?
Could it be that Oom or smth kills the view and the settings are not stored?
No actually, they are stored right away.
Still thinking about what could trigger this behaviour…
I am sorry I cannot reproduce it. On my phones it ONLY appears at the main exchange calendar (subcalendars work), linked over my domain via DNS to Office365.
I am moving away from MSFT anyway. I think it is an Office365 problem in my case, I will try it with an exchange account to mailbox.org now and reply then.
EDIT: No, it’s not an Office main cal issue, happens on all cals including subcals every restart.
Yes, for Exchange, it’s a “feature”. The sync is imposing the visibility declared on the server (previously, it was not the case, the visibility bit was not honored). For Google and CalDAV, the visibility is not transmitted, or at least not read and thus not taken into account.
That being said, it could be discussed if it’s wise to follow the visibility information sent by Exchange servers… But the Exchange plugin is closed source and I cannot do anything to it.
See https://github.com/sailfishos/contactsd/pull/1, I’ve identified at least one code path that can lead to visibility reset even for Google accounts. But I cannot figure out how it is related to @miqu description of his issue.
From my point of view I totally understand the rationale behind having server visibility separate from device visibility. From server usually means a web UI of somekind that you use to see your calendar. So I would see that as separate from devices. Though I do understand the rationale behind the other way also that there is just a calendar and its subvisibility. Where you sync it doesnt matter. But it does. 
Thx for your reply. Another point I’ll move to CalDAV. Having many different devices with different purposes, this “feature” is not wise 
Another thing. Is a week calendar or 3-5 days calendar really so hard to create?
About the Exchange “feature”, as I said, it may be changed by Jolla. They didn’t enable it actually. It was a by-product of some code simplification @flypig and I did on calendar visibility handling. Exchange is flipping the visibility bit of calendars and as far as I know it’s the only sync plugin that does it. But this bit was itself ignored and superceeded by a QSetting (or something similar) in the QML bindings. This added a lot of boiler plate in the QML bindings and any C++ code handling calendars was even not aware of it. So we removed the QSetting (it was the same for colours), which made the “feature” of Exchange to “appear”. The same treatment than the one that has been decided for colours in the sync plugins could be applied here in the Exchange sync plugin : flip the calendar visibility on the phone only if there is a visibility change on the server, otherwise keep the user choice on device.
Another thing. Is a week calendar or 3-5 days calendar really so hard to create?
In my opinion, it’s not difficult. In a quick thought about it, it seems that every pieces are already available in the QML bindings to get the information (the AgendaModel is flexible enough to get events for a week). It’s mainly a question of design and actually writing the QML files for it.
I’m quite reluctant in doing it myself for license reason. Jolla-calendar source code is proprietary and I would loose all written code. Fixing an issue in the QML files here and there is fine, doing a minor addition of some lines of QML that can be redone easily is still alright. But write an extensive length of QML without the possibility to reuse it later is a no go.
1 Like
thanks for your response! I wish I had time for coding again, my skills stopped at pascal / delphi and C (without+) and I have zero time as a selfemployed with family.
Couldn’t Rostelkom pay you some 10000-100000 bucks (€£$) for making a week view?
Couldn’t Rostelkom pay you some 10000-100000 bucks (€£$) for making a week view?
Actually no, at least they didn’t propose : -) …
All my contributions are done on my free time without being paid. That’s why I try to focus on open source parts only. It’s kind of sustainable coding : like that code can survive any bankruptcy or change in strategy. I wouldn’t be interested in writing proprietary code for money. I’m lucky to have a (nice) job for that (where created code is open source).
It’s completely off-topic, but the suggestion to implement a week view by the community hitched my curiosity and I will investigate it. And find a way to have it with an open source license…
3 Likes