I’m not completely sure about the custom type. All of these are Android standard, so I’m somewhat surprised they even need to be specified to show up. (BTW: google contacts use all of them, that’s a good way to check and compare.)
What do you suggest how these dates (OTHER and CUSTOM) should be represented in the vCard?
I did not see these among other users of x properties (mozilla, evolution etc.). So X-DAVX5-EVENTOTHER and X-DAVX5-EVENTCUSTOM may be it. The content format would be the same as for the other two types.
Now for the label for the custom type, if we follow what the mozilla addressbook does: For a custom event like 2021-01-17 derive an item id (maybe 2020117) and specify a label FirstShow in vcard as X-DAVX5-EVENTCUSTOM-20210117.LABEL:FirstShow. Maybe the id should be derived differently to allow different entries for the same day. (And maybe the label for an x property needs to be X-EVENTLABEL or such).
Side note: There is a DEATHDATE in RFC 6474 which is not accepted yet. With aCalender+ and carddav-sync I noticed the following: if I enter a custom event with label Todestag then it shows up in aCalendars’s event list with a special icon. I have no clue who in the chain (carddav-sync provider, Android, aCalendar) recognizes that localized custom label. I don’t think the sync provider is involved. So, even without syncing (but with a different contacts.xml) this could work, too.
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”
@rfc2822 I used the automatic Gmail setup from FairEmail to get access to that email inbox. Due to the fact that I’d set-up my phone the ususal way, by linking it to my Gmail account, all default apps, like e.g. the default email program, worked out-of-the-box on my Samsung phone. FairEmail was able to take over these Gmail credentials without any problems.
Unfortunately I cannot tell you if it also works without a preconfigured Gmail account.
That’s what I have assumed from the source code. But I also assume that it will only work with a preconfigured Google account, and users who use DAVx⁵ with Google often won’t have a Google account set up (otherwise they wouldn’t need DAVx⁵ and could just use the normal Google sync).
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?