Summary: | New field type: working hours | ||
---|---|---|---|
Product: | [Applications] kaddressbook | Reporter: | Dotan Cohen <kde-2011.08> |
Component: | general | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED INTENTIONAL | ||
Severity: | wishlist | CC: | tokoe, wstephenson |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Unlisted Binaries | ||
OS: | Unspecified | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Dotan Cohen
2010-01-14 11:58:35 UTC
Hej Dotan, having KAddressBook based on Akonadi doesn't mean we don't depend on vCard anymore... Akonadi is only an access layer, the storage is still done in vCard/Groupware Server/etc... So we should try to keep as compatible as possible. You can use a custom field for that as soon as they are back in 4.5 or later Ciao, Tobias Agreed - the more fields in the base Addressee, the harder it is to synchronise or to write groupware backends for. Extensions like this will be possible with Nepomuk ontologies, but how this will be represented in the UI is a completely open question. > You can use a custom field for that as soon as > they are back in 4.5 or later Custom fields are not flexible enough to let one query for information such as: 1) See which pizza restaurant is open on Friday at 02:30 in the morning. 2) See which museums will be open when your old friend comes to visit. 3) Which pharmacy is open on Saturday when your child is sick. If you are concerned about vCard compatibility, then the information could be stored in custom vCard fields. Or the information could be stored in a human-readable format as an amendment to the Notes field, that won't show in Kaddressbook but will show in other apps. Shall I suggest just such a format? > but how this will be represented in the UI is a > completely open question. Would you like me to write up a mockup? |