forked from AuroraMiddleware/gtk
1070c5849e
Since the ::changed implementation of GtkRecentManager implies a
synchronous write operation, when we receive multiple requests to emit a
::changed signal we might end up blocking.
This change coalesces multiple ::changed emission requests using the
following sequence:
• the first request will install a timeout in 250 ms, which will
emit the ::changed signal
• each further request while the timeout has not been emitted
will increase a counter
‣ if the counter reaches 250 before the timeout has been
emitted, then the RecentManager will remove the timeout
source and force a signal emission and reset the counter
This sequence should guarantee that frequent ::changed emission requests
are coalesced, and also guarantee that we don't let them dangle for too
long.
https://bugzilla.gnome.org/show_bug.cgi?id=616997
|
||
|---|---|---|
| .. | ||
| action.c | ||
| builder.c | ||
| crossingevents.c | ||
| defaultvalue.c | ||
| expander.c | ||
| filechooser.c | ||
| filtermodel.c | ||
| floating.c | ||
| liststore.c | ||
| Makefile.am | ||
| object.c | ||
| pixbuf-init.c | ||
| recentmanager.c | ||
| testing.c | ||
| textbuffer.c | ||
| treestore.c | ||
| treeview-scrolling.c | ||
| treeview.c | ||