72e2c77...
by
Christian Hilberg <email address hidden>
removed XFB base64 decoding (t.b.d. in backends)
* removed the XFB data base64 decoding from
Evolution, which potentially is backend-specific
* we require the backends to deliver decoded
UTF-8 text for XFB data (UTF-8 enforcement is
kept here, just in case)
821e211...
by
Christian Hilberg <email address hidden>
removed code dupe from libedataserver
* since we're actually linking to E-D-S already, we can use
e_util_utf8_data_make_valid() right away without dupe'ing
it
ae03f3b...
by
Christian Hilberg <email address hidden>
9148e9b...
by
Christian Hilberg <email address hidden>
comment cleanup
73c366c...
by
Christian Hilberg <email address hidden>
removed unneeded runtime warning
c715d68...
by
Christian Hilberg <email address hidden>
EMeetingTimeSelector: added XFB tooltip to the freebusy canvas
* the busy periods in the scheduling page of the meeting
time selector are no individual GtkWidgets, so we add
the tooltip to the canvas they're painted into and let
the tooltip callback function decide whether or not to
show a tooltip (only shown if the busy period we're
hovering over actually carries XFB information)
* there is intentionally no formatting or (translatable)
string additions nor styling involved to restrict the tooltip
to the absolute minimum, in order not to be confusing
or overloaded
d4905bc...
by
Christian Hilberg <email address hidden>
* extract X-SUMMARY and X-LOCATION XFB details from a
vfreebusy ical property (which is part of the ical
component we get from the backends when querying
free/busy information), either of which may be absent
* the values we get will be validated for UTF-8 conformance
(possibly being forced into) and length limited before
being stored into the EMeetingAttendee alongside the
other busy period details
a5717f6...
by
Christian Hilberg <email address hidden>
* added XFB details (summary, location) to the free/busy
data
* the data is stored as part of each EMeetingFreeBusyPeriod,
which are in turn stored in a GArray for each attendee
* since this array can get re-sorted while adding more busy
periods (and thus will the start addresses of the
EMeetingFreeBusyPeriod data segmets), earlier plans of
keeping XFB data in a hash table separate from the GArray
were dropped, since we cannot reliably use GArray indices
or EMeetingFreeBusyPeriod start addresses as references
into a separate data structure to get to the XFB data
(which may not be carried by every EMeetingFreeBusyPeriod,
but is optional)
* XFB data is not fixed-length, so EMeetingXfbData (part of
EMeetingFreeBusyPeriod) just keeps pointers to the XFB data,
which in turn introduces the need for a GArray clearing
function (which gets registered with the GArray and takes
care of freeing XFB strings, if the EMeetingFreeBusyPeriod
has any)
* e_meeting_attendee_add_busy_period() now takes XFB data string
arguments, each of which may be NULL (this follows the scheme
of the other arguments to this function, i.e. adding each
busy period detail as a separate argument)
0cc2d86...
by
Christian Hilberg <email address hidden>
added helper functions for XFB data (type)
* since EMeetingXfbData will be part of the freebusy
GArray data (EMeetingFreeBusyPeriod), it gets allocated
when EMeetingFreeBusyPeriod is, we just need to
clear/set it (hence no new()/free(), but clear()/set())
* e_meeting_xfb_utf8_string_new_from_ical() takes care
of UTF-8 validation and length limitation of the
summary/location strings we get since these will be
displayed as tooltips for busy periods
0d6af1c...
by
Christian Hilberg <email address hidden>
