Here one current example: I schedule in August 2020 a meeting, targeted for Fuji, for 2020-11-11 and send an .ics invitation, bundling tz definitions. Afterwards the Fuji experts change DST rules, so that the switch does not happen on 2020-11-08 but on 2020-12-20. The UTC offset calculations, included in the .ics invitation, are therefore for that meeting wrong. Nobody thinks on regenerating and resending the .ics file with new tz data. If the OS gets updates, then that event might be presented correctly, if the .ics interpreter ignores the bundled TZ definitions, if the .ics interpreter sees no bundled timezone definitions, or if the .ics interpreter shows to the user, that the bundled TZ definitions are outdated, and there are two possible times for the start.
There is no ultimate right way on technical level to prevent troubles here, not bundling the time zone definitions in the .ics file saves band width.
Hi everyone, first of all congrats on the fantastic app! 🙂
I think it would be a nice improvement if users could tell DavX to avoid syncing during certain time periods, e.g. overnight.
Currently, I’d prefer to have my syncing every hour, but the problem is this causes all of my server’s disks to wake up once per hour for the sync. During the day this isn’t too bad since the disks would often otherwise be awake, but overnight this causes lots of unnecessary disk wakes. It would be great if we could tell the app “only sync between 08:00 and 22:00”, for example, to avoid those unnecessary syncs.
My current workaround is set the syncs to happen every 4 hours, which helps with this issue a bit (only 1 unnecessary sync overnight generally). However, using this setting also makes my calendar pretty useless during the day unless I manually update all the time.
Some services don’t automatically pull contact photos from other services (gmail, yahoo, gravatar, etc). I’d like to suggest a feature where DavX could check if there’s a contact photo associated with an email address (from one of these other services), and pull it in.
Options could be given to “never overwrite existing pictures, or Overwrite existing pictures”
As for the Qt-CalDAV thing - I totally understand that CalDAV doesn’t have anything to do with Qt or the way it interprets color values. Qt also doesn’t have any idea about CalDAV. If you asked me, then I would say that this is just a total coincidence that Korganizer correctly displays calendar colors sent by the Runbox calendar service. The support for SVG color names was implemented in QColor for totally different reasons, not with Apple’s calendar-color in mind (Qt as a programming framework just supports SVG as one of many graphics formats, that’s why QColor needs to understand SVG color names). QColor, of course, supports also RGB(A) color values. And most probably Runbox chose to use SVG color names for their calendars because it was just more convenient for them (we give users 120 predefined SVG colors for their calendars - they be happy; we have less work - we be happy as well).
Unfortunately, I also have no knowledge of the Apple’s calendar-color specification. From the DAVx5 logs I just assumed that these color names are Apple-defined and are part of their calendar-color specification. Turned out that my assumption was wrong. It seems that this caused a lot of unnecessary confusion 😀
Thank you so much for the reply. I was not aware that for this to work, the CalDAV client had to write this into the remote calendar (and thus require a calendar with r/w privileges) - I thought it could be added only locally during sync.
I am actually using BC2, so I will give their birthday calendar implementation a spin.
a) represent Nextcloud fields such as Language, Relationship, Geo, Timezone, Deathdate etc (most of which are RFC standard) on the Android handset.
b) sync the custom fields created in Android apps that allow it, so at the very least the data is retained in the vCard, if not displayed at the server end. I assume these properties are stored by the relevant apps in a custom way…?
It would be possible to store such fields in the Contacts database, but with a proprietary (custom) MIME type. As I see it, the most difficult part is that DAVx⁵ only stores/retrieves the data, while the Contacts apps provide UI. So implementing this would require cooperating with Contacts apps. Do you know Contacts apps whose developers would be interested in that?
Also, just for curiosity: What are your most needed additional fields and what is your use case for that?
synch only between X o’clock and Y o’clock
synch only on ( ) Monday ( ) Tuesday ( ) Wednesday… etc
The reason for this request is servers that are not available at certain times, eg office machines that are switched off at night and at the week end. Choosing time frames, when to synch and when not, would avoid error messages.
@rfc2822 Thanks for the fast response!
No, there are no real problems with it. I think SSO is a bit easier to configure, though, since you don’t need to enter your credentials another time if you already configured the Nextcloud app.
An idea to improve things could be to maybe make Nextcloud’s Login Flow a bit easier to discover from the DAVx5 app by adding an additional option below extended login when adding a new account directly?