g_variant_new("as", NULL); now gives an empty array of strings, for
example.
This was documented as working already, but was never actually
implemented (due to the fact that it muddies the water when considering
maybe types). It's being implemented now because its convenience to
programmers exceeds any damage done to the conceptual purity of the API.
This will help applications such as zeitgeist's datahub to collect
more complete information about application launches, as the "actor"
of a launch is important for zeitgeist's magic to work properly.
If we were the initial connection owner, unref will destroy the
connection immediately, and we may lose messages. Asynchronously
flush to avoid that.
https://bugzilla.gnome.org/show_bug.cgi?id=641411
Some people are trying to write code that calls g_application_register()
then checks to see if we became the primary name owner before exporting
objects. This sort of approach worked with libdbus-1 because method
calls to the freshly-acquired name would not be dispatched until the
application returned to the mainloop. With GDBus, however, dispatches
can occur at any time (including in the brief space between acquiring
the name and actually registering the object).
Add documentation to make it clear that you should not expect this to
work.
Bug #640807 makes a reasonable case for why it's better to have your
program crash outright in the case of memory errors. With this
modification, GVariant is far more likely to do that in the case that a
GVariant pointer is used shortly after being freed.
When g_key_file_parse_data() encountered \n, it was checking the previous
character in the current input buffer for a \r to erase, rather than the
previous character in the parse buffer. If g_key_file_load_from_file()
was given a file with a \r\n sequence straddling a 4 KB boundary, the \n
would be the first character in the input buffer, so the \r would not be
properly stripped.
Bug #640695.
Found-by: Jan Harkes <jaharkes@cs.cmu.edu>
