It's there even when you delete an event or create an event in calendar view. I meant even in personal calendar.

Confirming. I see it's "only" about painting, it shows changes immediately when I "force" repaint of the table, like by choosing the preview panel or such. I'm searching what event got lost or what broke in the repaint function.

Created attachment 172824 [details] [review]
eds patch

for evolution-data-server;

Hrm, I realized it's not only about painting. This is a regression from my changes in bug #625115, which uncovered this behaviour.

It's funny how this behaves, because it does basically this:
a) you click on the checkbox in the Tasks view to complete/uncomplete the task
b) this is received, checkbox value is updated, and then is also updated
   the task in the e-calendar-factory
c) the factory backend behind this tasks list receives the change and if it
   updates its store then it notifies all views about the change
d) the model in the table receives this change notification
   from e-calendar-factory, and notifies table about row change, which finally
   repaints the row which was clicked on in a)

The all repaint fun goes through e-calendar-factory and GDBus. The difference before and after patch from bug #625115 is that before were notified all views immediately, but after it there was some timeout (about 2 seconds) to cumulate more updates and push them in once. I changed this to notify about changes in the 'done' view almost immediately. The 'done' view is a view where the initial populating of it was already done.

Created commit 8600073 in eds master (2.91.2+)
Created commit dec1d60 in eds gnome-2-32 (2.32.1+)