Update sources in calendar chooser when source connects

[benjaminkitt]

If calendar chooser is displayed before sources are fully loaded, re-renders sources so that all calendars become available.

This PR blocks elementary/wingpanel-indicator-datetime#299 as without it the added functionality is largely useless. The implementation of the linked PR relies on the existing method of launching the calendar application with a flag (--add-event) that tells the application to open a new event dialog. However, as currently implemented the new event dialog is loaded prior to all event sources having been initialized, so it is impossible to choose a destination calendar for the new event.

This PR addresses this issue by 1) displaying the calendar selection regardless of the number of calendar sources the user has and 2) re-rendering the calendar options when sources are updated.

While a DBus implementation for adding new events from wingpanel would be a better option (and one I will explore in future,) this change does at least make the aforementioned flag usable.

[benjaminkitt]

I considered adding this element only once all sources were initialized but given that the registry is accessed within the CalendarChooser component, it would have led to a lot of extra code. The only downside to this approach is that a user who only has one calendar will only have one source to select from in the dropdown. I think this is a reasonably minor UX tradeoff.

[mcclurgm]

I think this is a fine tradeoff. From my perspective (not on the UX team) having the selector present even with only one source may be good for consistency.

My only concern is that this could lead to a state where not all the sources are available in the chooser. Depending how long that state lasts it may be worthwhile to add a spinner or something of the sort, if there's an easy way to access a state that indicates we're still loading sources. This may not be much of an issue though.

[benjaminkitt]

Extracted render code into a private method so it can be used both in the initial constructor and as an event handler.

[mcclurgm]

Worth noting that this will also fix an issue where no calendars appear if you open an ICS file from import with Calendar not already open.

[mcclurgm]

Sorry my review is taking a while. I'm working my way through the code.

I'm encountering a crash when I open an ICS file on a cold start (the app and daemon are not running) that is not present in master. To see this crash, run io.elementary.calendar ics-file.ics where ics-file.ics is some valid file. It'll segfault. Here's a backtrace I got from gdb:

Thread 1 "io.elementary.c" received signal SIGSEGV, Segmentation fault.
0x00007ffff7d686e1 in g_type_check_instance_is_fundamentally_a () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
(gdb) bt
#0  0x00007ffff7d686e1 in g_type_check_instance_is_fundamentally_a () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#1  0x00007ffff7d45942 in g_object_ref () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#2  0x00005555555c3293 in _g_object_ref0 (self=0x7ffff7e9c73c <g_hash_table_lookup+44>)
    at ../src/Widgets/CalendarChooser.vala:130
#3  0x00005555555c3faa in maya_view_widgets_calendar_chooser_set_current_source
    (self=0x555555bcca20, value=0x7ffff7e9c73c) at ../src/Widgets/CalendarChooser.vala:29
#4  0x00005555555c4a57 in maya_view_widgets_calendar_chooser_constructorPython Exception <class 'gdb.error'> No type named TypeNode.: 

    (type=, n_construct_properties=0, construct_properties=0x0) at ../src/Widgets/CalendarChooser.vala:39
#5  0x00007ffff7d46b6d in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#6  0x00007ffff7d47b45 in g_object_new_with_properties () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7  0x00007ffff7d486f1 in g_object_new () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8  0x00005555555c3ed8 in maya_view_widgets_calendar_chooser_constructPython Exception <class 'gdb.error'> No type named TypeNode.: 
 (object_type=)
    at ../src/Widgets/CalendarChooser.vala:20
#9  0x00005555555c3ef7 in maya_view_widgets_calendar_chooser_new () at ../src/Widgets/CalendarChooser.vala:20
#10 0x00005555555779cd in maya_view_import_dialog_constructPython Exception <class 'gdb.error'> No type named TypeNode.: 
 (object_type=, files=0x555555840b90, files_length1=1)
    at ../src/ImportDialog.vala:53
#11 0x0000555555577c1b in maya_view_import_dialog_new (files=0x555555840b90, files_length1=1)
    at ../src/ImportDialog.vala:24
#12 0x000055555557629d in maya_application_real_open
    (base=0x5555557a0130, files=0x555555840b90, files_length1=1, hint=0x555555730550 "")
    at ../src/Application.vala:125
#13 0x00007ffff7259502 in  () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#14 0x00007ffff7d40a56 in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#15 0x00007ffff7d5fb48 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#16 0x00007ffff7d600f3 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#17 0x00007ffff72b5c75 in  () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#18 0x00007ffff72b5f52 in g_application_run () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#19 0x0000555555576ca4 in maya_application_main (args=0x7fffffffe3e8, args_length1=2) at ../src/Application.vala:195
#20 0x0000555555576d29 in main (argc=2, argv=0x7fffffffe3e8) at ../src/Application.vala:181

[mcclurgm]

I believe I've tracked down the issue, and I don't think it's your fault, so I won't consider it a blocker for this PR. It looks like you uncovered a race condition. It appears that on constructing a CalendarChooser from a cold start, the registry property of the EventStore is null. From my testing, it seems like the error occurs before the registry is initialized in the async open method.

[mcclurgm]

May I ask how you're testing this? Thanks to the crash I mentioned above I can't figure out how to get to a state where the sources aren't already loaded before the CalendarChooser is initialized, so I'm not sure how to test this. In general I think the code makes sense though.

My one concern is that this could lead to a hitch if a lot of calendars are added quickly, leading to many refreshes of the list. This may be outside the scope of this PR, but it seems like it should be possible to add the sources one at a time to the ListBox. The EventStore.connect signal does include a source parameter that we could use to see exactly what source is being added. (This would also remove the requirement to share the registry variable throughout the class, for whatever benefit that would have.) This may have side effects I'm not considering though. If you'd rather keep it simple here that's fine, I won't consider this a blocking issue.