Federated_Computer/federated-calendar
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
3,480 Commits 3 Branches 0 Tags
94413c26b11f4fe77def5c5fb709c2933a23e4b8
Commit Graph
40 Commits
Author SHA1 Message Date
Georges Basile Stavracas Neto 94413c26b1 event: Remove event cache 
It's for the best. The cache was being more
problematic than it was worth it.
 2020-04-01 21:06:51 -03:00
Georges Basile Stavracas Neto 78248bec5e calendar: Mark all properties as G_PARAM_EXPLICIT_NOTIFY 
We explicitly notify them all, so mark them as such. Otherwise,
GLib notifies it when changing these properties through bindings
and such.
 2020-04-01 21:06:50 -03:00
Georges Basile Stavracas Neto 90597ca128 calendar: Only notify visibility when it changes 
Otherwise we get weird double-notify issues from it.
 2020-04-01 21:06:50 -03:00
Georges Basile Stavracas Neto f182813e49 event: Protect event cache with a lock 
We'll be creating events from multiple threads soon,
so make sure the event cache is protected enough.
 2020-04-01 21:06:50 -03:00
Georges Basile Stavracas Neto 047078d67d build: Move foward typedefs to gcal-types.h 
Standard practice; gcal-types.h is meant to only be
used by header files.
 2020-04-01 21:06:50 -03:00
Niels De Graef 4d05ffb9d3 Don't forget to chain up to parent finalize 
This can give a small memory leak and can prevent the necessary closing
of resources.
 2019-12-02 19:53:59 +00:00
Georges Basile Stavracas Neto 87c1ffb9d5 Reimplement alarm support 
This is a complete reimplementation of alarms in Calendar.

Rejoice.
 2019-12-02 16:41:56 -03:00
Georges Basile Stavracas Neto 58974cb7e2 manager: Only remove connected calendars 
The "source-removed" signal can pass any kind of source,
including source collections that even have the calendar
extension, but are not connected.
 2019-10-09 13:02:35 -03:00
Georges Basile Stavracas Neto 1c39e501f6 calendar: Always initialize color 2019-10-09 12:37:01 -03:00
Georges Basile Stavracas Neto 262cd40eec manager: Instrument removing calendars 2019-10-09 12:37:01 -03:00
Georges Basile Stavracas Neto 1308e33f1d manager: Always return if calendar creation fails 
This is an embarrassing mistake: when an error is propagated,
we always need to return! The error matching should only be
used for deciding whether to warn or not.

https://gitlab.gnome.org/GNOME/gnome-calendar/issues/470
https://gitlab.gnome.org/GNOME/gnome-calendar/issues/264
 2019-10-09 12:37:01 -03:00
Michael Catanzaro 50b6d00784 manager: add GcalContext property 
This improves access to the GcalContext inside GcalManager.

Also, remove test-manager since it only tests that gcal_manager_new()
returns non-NULL.
 2019-09-19 16:04:04 -05:00
Michael Catanzaro 8e6a3b9f3f Fix crashes when e_cal_util_get_system_timezone() returns NULL 
The return value is nullable, but gnome-calendar fails to check it.

Because the nullable return value is inconvenient for us, we can instead
add and use gcal_context_get_icaltimezone() to supplement the existing
gcal_context_get_timezone().

We'll also need a function to convert from GTimeZone to ICalTimezone,
gcal_timezone_to_icaltimezone().

Fixes #419
 2019-09-19 16:01:44 -05:00
Michael Catanzaro d0d4166d23 context: initialize GcalSearchEngine later 
After the next commit, GcalSearchEngine will require GcalContext to be
ready to initialize itself.
 2019-09-19 15:37:45 -05:00
Michael Catanzaro 18ae67cb59 Use more g_signal_connect_object() 
Most of these are probably paranoid, not bugs. I haven't done an
exhaustive review to see what really needs it: that would be
time-consuming and require significant familiarity with the Calendar
codebase. This was just a quick check. Anyway, I vote for paranoid
when it comes to using g_signal_connect() regardless. It's dangerous,
and there's no reason to ever leave a signal connected after the user
data object has been destroyed.

Fixes #423
 2019-09-14 23:28:42 +00:00
Georges Basile Stavracas Neto 450aa5e158 log: Remove g_get_current_time 2019-09-14 10:46:14 -03:00
Georges Basile Stavracas Neto e39bd95c87 log: Use g_autofree 2019-09-14 10:39:38 -03:00
Michael Catanzaro 5d2c0faf41 Fix use-after-free in GcalManager code 
This was originally discovered and fixed by Milan Crha; I'm just
forward-porting his fix to the master branch. self->clients takes
ownership of this source but we don't currently have ownership here,
leading to a double free vulnerability.

Fixes #435
 2019-09-03 12:07:26 +00:00
Michael Catanzaro 748b7207e7 Don't leave dangling pointers in the GcalEvent cache 
The cache has an unowned pointer to the GcalEvent's UID. We need to
update the cache with the GcalEvent's new UID to avoid use-after-free.

Fixes #434
 2019-08-25 17:39:01 +03:00
Georges Basile Stavracas Neto b49486d0f9 calendar: Disconnect from the visible signals as well 
Missed from the initial implementation.
 2019-07-13 19:54:47 -03:00
Georges Basile Stavracas Neto 07acf540ae calendar: Disconnect from the correct object 
The name changed signal comes from the ESource, not
the extension.
 2019-07-13 19:54:17 -03:00
Georges Basile Stavracas Neto bb2a1321be calendar: Use gulong for signal handlers 
They are unsigned longs, not unsigned ints.
 2019-07-13 19:52:53 -03:00
Georges Basile Stavracas Neto 1d6dee8bbb manager: Avoid reentrancy 
While deleting the calendar, we may run into a situation
where the GcalCalendar instance is destroyed before the
GcalManager:calendar-removed signal is emitted, causing
us to emit the signal with a destroyed object.

Prevent that by increasing the ref count before emiting
the signal.
 2019-07-13 19:51:02 -03:00
Georges Basile Stavracas Neto a2d15697d9 log: Increase prefix width 
GcalCalendarManagementDialog is too wide and breaks the log
layout, so increase the spacing to fit it.
 2019-06-24 21:32:58 -03:00
Georges Basile Stavracas Neto badd1fb0f1 calendar: Fix double free 
The GError is unreferenced twice.
 2019-05-24 21:25:28 -03:00
Milan Crha a0cae4356a Port to libecal-2.0 
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/merge_requests/70
 2019-05-17 21:58:55 +02:00
Georges Basile Stavracas Neto 198180d023 manager: Fix typo 2019-05-10 13:44:43 -03:00
Georges Basile Stavracas Neto f4c4a91465 manager: Add 'synchronizing' property 
Will be useful to know if there are any clients being
synchronized.
 2019-05-10 12:42:13 -03:00
Georges Basile Stavracas Neto 7ad0f100a7 manager: Properly bind default calendar 
We need to convert from ESource to GcalCalendar.
 2019-05-10 11:20:51 -03:00
Georges Basile Stavracas Neto a2609d6853 project: Reorganize much 2019-05-04 19:48:40 -03:00
Georges Basile Stavracas Neto bb8d5b92ce manager: Handle default calendars via GcalCalendar 2019-05-04 12:05:39 -03:00
Georges Basile Stavracas Neto ada9bcc473 calendar: Fix signal handler cleanup on finalize() 2019-05-04 12:05:39 -03:00
Georges Basile Stavracas Neto 245df513d7 event: Simplify color handling 
We can use GcalCalendar::color property directly now.
 2019-05-04 12:05:39 -03:00
Georges Basile Stavracas Neto 02cbfdadf2 calendar: Make it a derivable class 2019-05-04 12:05:39 -03:00
Georges Basile Stavracas Neto df182d1b88 manager: Remove "loading" property 
The stack is robust enough to handle dynamically
loading the calendars.
 2019-05-04 12:05:39 -03:00
Georges Basile Stavracas Neto e7c6120133 manager: Remove gcal_manager_is_client_writable() 
It is now handled by GcalCalendar, and nobody else uses
it.
 2019-05-04 12:05:39 -03:00
Georges Basile Stavracas Neto e800bb2476 manager: Remove gcal_manager_enable/disable_source() 
This is now managed by GcalCalendar itself.
 2019-05-04 12:05:39 -03:00
Georges Basile Stavracas Neto 2ef1cbc463 manager: Toggle data model sources when changed 
Instead of other classes needing to manually set and
unset whether a source is registered in the data model,
we can now simply call GcalCalendar.set_visible() and
have the model be updated for us.
 2019-05-04 12:05:39 -03:00
Georges Basile Stavracas Neto 64fa11f4c0 calendar: Fix double unref 2019-05-04 12:05:39 -03:00
Georges Basile Stavracas Neto 1a5ff545a2 project: Move a few classes to core/ 2019-05-04 12:05:39 -03:00