That is actually planned. We already support it for Google Contacts, but we also plan to support generic CardDAV/CalDAV “client-mode” in the future.
Development hasn't started (besides the Google Contacts sync feature, which we pulled due to the abysmal quality of the Google CardDAV API).
We are still very interested in this feature and are currently thinking about something that might even be a little independent from the main fruux product and do server to server syncing, backups and maybe a few other things that could work with fruux, but also with other providers.
We're planning to do a mailing about this in a little while.
Repeatable tasks and alarms are fully supported, it’s just our webapp thats still lacking a bit in that regard. Adding this functionality to our webapp is of course planned.
Not yet supported in the webapp sadly, but fully supported with any proper calendar app that syncs with fruux: https://fruux.com/supported-devices/
Many clients don't support recurring tasks. Apple Reminders for example (which is a quite feature-rich CalDAV client also doesn't really comply with the CalDAV/iCalendar specs there).
Our basic accounts are of course not limited whatsoever in this regard. The only limitation they have is the number of devices you can sync and the number of calendars/addressbooks/tasks lists you are able to share with others.
Please let's keep this thread 'clean' (this is our feature request & ideas system) and use our support for actual support questions. :-) Just email us any time via support (at) fruux (dot) com. Thanks!
U2F is not yet (natively) supported on Safari and iOS, so doesn't make sense (yet) to rely (solely) on it.
OpenTasks is compatible with fruux b.t.w., so you could also use OpenTasks.
Just to clarify:
It's already possible to configure the sort order. You'd like to also change the way it's displayed and not just the sort order, correct?
We already do versioned backups under the hood (think of it as Time Machine or git for contacts/calendars/tasks). A web frontend to also make this functionality available to our users is planned. Unfortunately no ETA yet.
That's correct. This feature is implemented in the system, but no user interface exist (yet). Our support however is able to assist with this.
Localizations (e.g. a German version) are planned, but a completely different task. But once a localized version exists, I agree that it should be an option here, too. :-)
We've actually implemented this already a few days ago. Just the user interface that makes it easy to generate the URL for the public calendar is still missing.
But you can already use this manually by appending parameters to the URL of your public calendar. We support the following parameters:
- calendarView: month, list, week, day
- dateFormat: DD/MM/YYYY, MM/DD/YYYY
- startOfWeek : 0, 1, 2, 3, 4, 5, 6 (0=Sun, 1=Mon, ..., 6=Sat)
- timeFormat : 12, 24
- timezone: Europe/Berlin (If not present, the visitors timezone is detected)
- selectedDate: YYYY-MM-DD
If a parameter is not present, the default will be used.
Here's an example for the calendar that's embedded on fruux.com:
Could you elaborate a bit? What features are missing for you or what should be different?
Did you know that you could already have that - fully powered by open standards (instead of Google proprietary stuff):
None of the existing implementations could be integrated "as is" at our scale or really meets our quality standards.
If we're going to support ActiveSync, we have to build it ourselves.
But you're right, just split this ideas into two ideas (even they are related, because both would happen via ActiveSync). This idea tracks ActiveSync support for mobile devices.
Integration with other Exchange servers is now tracked in this idea:
We’d love to support Safari bookmarks – unfortunately there is no open standard (yet) to make it happen. Ones there is a way to do it, we’d probably be very interested to make it happen.
fruux is now cross-platform and based on a completely new technology (CardDAV and CalDAV). The old/legacy fruux (which only worked on Macs) was based on a proprietary Apple technology that has been deprecated (http://en.wikipedia.org/wiki/Deprecation) by Apple in Mac OS 10.7 Lion.
Support for other protocols is something we're looking into, but we'd probably prefer doing it from scratch, because the existing stuff thats out there wouldn't scale for us. So this is unfortunately not a -super-short-term- kind of thing.
11 votesAdminfruux (Admin, fruux) supported this idea ·