Only resolve the link at the point that we pull it through the API
rather than at the point that we first are told about it. This reduces
the lifespan of subscriptions and, more importantly, avoids a tricky
reference cycle issue.
Each test needs to remove the sources that it attaches
to the default main context, or else things will work
fine in isolation, but go bad in a full test run.
The code assumes in various places that ':' does not occur
in attribute names. We are a little more strict than that,
and only allow lowercase ASCII, digits and '-'.
There are no public 'exporter' objects, so don't allude to them
in the function names. At the same time, we want to make it clear
that these functions are D-Bus specific.
The new APIs are
g_action_group_dbus_export_start
g_action_group_dbus_export_query
g_action_group_dbus_export_stop
g_menu_model_dbus_export_start
g_menu_model_dbus_export_query
g_menu_model_dbus_export_stop
Raised by Matthias in bgo#665685 but which I didn't spot until after pushing
commit 3ac7c35656.
Renames G_UNICHAR_MAX_DECOMPOSITION_LEN to G_UNICHAR_MAX_DECOMPOSITION_LENGTH
and fixes a few documentation issues.
See: bgo#665685
After questioning the semantics of flush on IRC, it seemed necessary to
clarify what flushing is supposed to do. The Linux man page for fflush()
seemed to cover it perfectly, so I just copied it.
I did not add the "via the underlying write mechanism" part as that in
my opinion is not something subclasses should need to guarantee.
This patch makes GFileMonitor to emit EVENT_CHANGES_DONE_HINT when
EVENT_CREATED is emitted but the file is not opened for writing.
On file moves across different mounted volumes, inotify will always emit
IN_CREATE and IN_CLOSE_WRITE (plus other events).
This translates into GIO's _EVENT_CREATED and _EVENT_CHANGES_DONE_HINT.
On file moves across the same mounted volumes, inotify will emit
IN_MOVED_FROM/IN_MOVED_TO which will be translated into
_EVENT_DELETED/_EVENT_CREATED GIO's side. No _EVENT_CHANGES_DONE_HINT is
emited afterwards.
Under such circumstances a file indexer does not know when actually the
file is ready to be indexed, either waiting too much or triggering the
indexing twice. On small devices it's not advisable.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=640077
Bug-NB: NB#219982
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Tomas Bzatek <tbzatek@redhat.com>