The previous patch to simplify the GSettings commandline tool by making
more use of global variables went a bit too far and broke 'gsettings
monitor' when used without a specific key.
Fix that up again.
The static analyser (correctly) considers a type check to fail if the
variable is NULL. In this case, the address must be non-NULL as no error
was thrown by g_socket_connection_get_remote_address(), but the static
analyser doesn’t know this.
Add a non-NULL assertion anyway, both to shut the analyser up, and
because it’s good extra testing.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=113075
These prevent some false positives from the static analyser which are
caused by it not inspecting the invariants of
g_subprocess_communicate[_utf8]_finish() (i.e. that stdout and
stdout_str will always be set unless an error was returned).
They’re also good testing anyway.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=113075
If the initial part of the header (‘MIME-TreeMagic’) is valid, but the
following line does not start with ‘[’ (i.e. is not a valid section
line), insert_matchlet() will be called with a NULL match pointer, and
will crash with a NULL pointer dereference.
Fix this by bailing out if a valid section line isn’t encountered before
the first insert_matchlet() call (i.e. between the header line and the
first data line).
Note that this has not been tested against a real treemagic file; the
fix is purely theoretical.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=113075
In the case that (n_fds == 0 && fds == NULL), memcpy() would be called
against a NULL src pointer. Even though the number of bytes to copy is
0, avoid the possibility of a crash by only calling if fds is non-NULL.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=113075
The static analyser will check dynamic type assertions and assume that
if they fail, the variable can either have the wrong type, or be NULL
(which is correct). The analyser doesn’t know that other constraints in
the API ensure the variable is non-NULL.
Add a non-null assertion to help the static analyser and shut it up in
this case.
https://bugzilla.gnome.org/show_bug.cgi?id=113075
This can happen if the hash table lookup for ‘noncefile’ fails, and
hence the first ‘goto out’ is hit, at which point resolver is still
NULL.
Found with scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=113075
Be a little bit more careful in regards to initializing a primitive type
variable before passing it by reference, as it could have random stuff
in the variable's address depending on the CRT, such as MSVCR110.DLL,
causing random, invalid stuff being written in that address.
This will fix this test when built with Visual Studio 2012.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
G_OS #ifdefs are only available once glibconfig.h has been
evaluated ; that is, after including glib headers.
Move this block down so it gets correctly evaluated.
Make it possible to skip the terminal-launching test simply
by setting DISPLAY= . Previously, you had to unset DISPLAY,
which is a little more cumbersome.
https://bugzilla.gnome.org/show_bug.cgi?id=711178
One testcase was launching appinfo-test from a GAppInfo that
does not have a filename. In this case, the G_LAUNCHED_DESKTOP_FILE
envvar is not exported. Make appinfo-test deal with that, without
spewing warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=711178
The actions test tests the GSimpleActionGroup API. Maybe this
should be moved to use GActionMap, but for now, just disable
the deprecations.
There was also one test that wasn't actually hooked up, so
do that as well.
Most _list_schemas() uses were to check for the availability
of a particular schema. g_settings_schema_source_lookup() is
a better way to do this.
https://bugzilla.gnome.org/show_bug.cgi?id=712315
In Windows development environments that have it, <unistd.h> is mostly
just a wrapper around several other native headers (in particular,
<io.h>, which contains read(), close(), etc, and <process.h>, which
contains getpid()). But given that some Windows dev environments don't
have <unistd.h>, everything that uses those functions on Windows
already needed to include the correct Windows header as well, and so
there is never any point to including <unistd.h> on Windows.
Also, remove some <unistd.h> includes (and a few others) that were
unnecessary even on unix.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Assume unix platforms support the original POSIX.1 standard.
Specifically, assume that if G_OS_UNIX, then we have chown(),
getcwd(), getgrgid(), getpwuid(), link(), <grp.h>, <pwd.h>,
<sys/types.h>, <sys/uio.h>, <sys/wait.h>, and <unistd.h>.
Additionally, since all versions of Windows that we care about also
have <sys/types.h>, we can remove HAVE_SYS_TYPES_H checks everywhere.
Also remove one include of <sys/times.h>, and the corresponding
configure check, since the include is not currently needed (and may
always have just been a typo for <sys/time.h>).
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Assume all supported platforms implement C90, and therefore they
(correctly) implement atexit(), memmove(), setlocale(), strerror(),
and vprintf(), and have <float.h> and <limits.h>.
(Also remove the configure check testing that "do ... while (0)" works
correctly; the non-do/while-based version of G_STMT_START and
G_STMT_END was removed years ago, but the check remained. Also, remove
some checks that configure.ac claimed were needed for libcharset, but
aren't actually used.)
Note that removing the g_memmove() function is not an ABI break even
on systems where g_memmove() was previously not a macro, because it
was never marked GLIB_AVAILABLE_IN_ALL or listed in glib.symbols, so
it would have been glib-internal since 2004.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
My application (hotssh) would like to get the resolved address from DNS,
before we start the connect().
We could add a new event, but it's easy enough to just cache it on the
GSocketConnection; this avoids any new API.
https://bugzilla.gnome.org/show_bug.cgi?id=712547
It makes sense to match on GenericName in case an application does
not provide any keywords, but the Keywords field has been added
to explicitly support the search case, while GenericName was used
to be displayed in menus, so it makes more sense to consider
Keywords more (or equally) relevant for search.
https://bugzilla.gnome.org/show_bug.cgi?id=711640
Just copy the schemas to the builddir and compile them in place instead
of trying to mess around with creating the compiled file in a different
dir. This solves issues in the summary/description testcase when
GSettings expects the usual situation of having the .xml files present
in the same directory.
We need to check for the correct line endings on Windows (\r\n) for the
echo tests and currently need to skip the test_echo_eof test there, as
it depends on the cat utility that is not normally found on Windows, and
using an external installation of cat via MSYS or Cygwin would render the
test program to hang as cat waits for user input.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
Various tests were depending on local_error being set by a callback
when it could never have been the case. Simplify async error detection
logic in those cases, and fix leak of GError.
https://bugzilla.gnome.org/show_bug.cgi?id=711802
We had a GApplication testcase that handled both open and commandline.
This only way that this worked was by implementing the commandline
handler without actually setting the HANDLES_COMMAND_LINE flag.
This behaviour is now invalid, so just rip out the offending part of the
test.
https://bugzilla.gnome.org/show_bug.cgi?id=711099
The first time this function is called we load all of the keyfiles in
the directory, ignoring the 'Hidden' ones and build an index out of the
interesting fields using g_str_tokenize_and_fold().
We do prefix matching on the tokens to find relevent desktop files.
Right now this is implemented as a hashtable that we iterate over,
checking prefixes on each token. This could possibly be sped up by
creating an array, but it's already pretty fast...
https://bugzilla.gnome.org/show_bug.cgi?id=711557
...so that the generated code will build on all platforms, as compilers
like Visual C++ does not like #ifdef checks during a definition/use of
a macro.
https://bugzilla.gnome.org/show_bug.cgi?id=711049
In each DesktopFileDir, store a list of desktop files for that
directory. This speeds up opening desktop files by name because we can
skip statting in directories that we know don't have the file and also
speeds up _get_all() because we can avoid enumeration.
This also improves our support for dealing with names like
'kde4/kate.desktop' (equivalent to kde4-kate.desktop) since we find out
about all of these files are the start and don't need to guess about
which '-' to change to a '/'. It also means that we can easily deal
with more than one level of such prefixes.
We use a file monitor to watch for changes, invalidating our lists when
we notice them.
https://bugzilla.gnome.org/show_bug.cgi?id=711520
Include unistd.h only on *NIX and define items as necessary on Windows,
also replace instances of ssize_t with the GLib-equivilant gssize so to fix
the build on platforms that do not have ssize_t, such as Visual C++.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
We need to use g_content_type_get_mime_type() to look up the mime type of
the file from the registry on the content type that was acquired on
Windows, as g_file_info_get_content_type() does not acquire the
file mime type (unlike on *NIX).
g_content_type_get_mime_type() on *NIX is more or less an no-op as it
simply returns the g_strdup()-ed version of the passed-in content type.
This will enable the resources test to pass on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
The overridden implementation of the skip method for
GLocalFileInputStream allows skipping past the end of the file which is
inconsistent with the documentation. Prevent this by first seeking to
the end of the file and then seeking backwards from there as much as
is necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=711048
If the goal is to make sure we don't have a dbus connection, it has
to call g_test_dbus_unset() instead which is much more complete.
In this case, g_test_dbus_unset() is called already, so it should be
fine.
https://bugzilla.gnome.org/show_bug.cgi?id=697348
This is to avoid having again the subtil bug in dbus-appinfo.c:
session_bus_down() was called before g_test_run() so the test was
running on the user's dbus session.
https://bugzilla.gnome.org/show_bug.cgi?id=697348
A reference to the session bus is now stored in GNotificationBackend.
Remove the extraneous one in the gtk backend and stop using it in
withdraw_notification.
https://bugzilla.gnome.org/show_bug.cgi?id=711051
Don't hold the lock when calling the user's callback during
g_cancellable_connect() for the case that the cancellable has already
fired.
Taken from a patch by Alex Larsson.
Doc updates from Colin Walters.
https://bugzilla.gnome.org/show_bug.cgi?id=705395
If someone calls org.gtk.Actions.Describe on a non-existent action then
return an exception instead of a trivial description (disabled, no
state, etc.).
https://bugzilla.gnome.org/show_bug.cgi?id=687185
If someone calls org.gtk.Actions.Describe on a non-existent action then
return an exception instead of a trivial description (disabled, no
state, etc.).
https://bugzilla.gnome.org/show_bug.cgi?id=687185
g_object_set() allowed us to bypass the usual checks that the state
doesn't change type and also leaked.
Fix that up by turning the state into a construct property (so that it
always gets set once during construction, even if only to NULL) and
then route the further sets through the C API so that they are subject
to the same checks.
https://bugzilla.gnome.org/show_bug.cgi?id=696424
Ignore qualified (in the XML namespace sense) tags and attributes when
compiling GSettings schemas.
This will allow people to add custom tags and attributes to their schemas
without tripping up the compiler.
https://bugzilla.gnome.org/show_bug.cgi?id=635641
Ignore qualified (in the XML namespace sense) tags and attributes when
parsing D-Bus introspection XML.
This will allow people to add custom tags and attributes to their D-Bus
interfaces without tripping up GDBus.
https://bugzilla.gnome.org/show_bug.cgi?id=665634
Stop using the recently-deprecated GSettings APIs.
Use the GSettingsSchema-based APIs instead.
This fixes a number of bugs and also a net reduction of code. In
particular, list-schemas will now work in context of a given --schemadir
argument.
https://bugzilla.gnome.org/show_bug.cgi?id=695558
The number of arguments passed to each function is about to increase, so
just use global variables instead.
This is a commandline tool, after all...
https://bugzilla.gnome.org/show_bug.cgi?id=695558
Add g_settings_schema_has_key() and _get_range(), _range_check(),
_get_value_type(), _get_default_value() methods on GSettingsSchemaKey.
Deprecate the equivalent APIs on GSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=683017
Add two new APIs: g_settings_get_user_value() and
g_settings_get_default_value(). Together, these should allow the
inspection of all interesting cases of "is this key set?" and "what
would happen if I reset this key?"
https://bugzilla.gnome.org/show_bug.cgi?id=668233
Add two boolean parameters to our internal getter utility function in
anticipation of the coming addition of g_settings_get_user_value() and
g_settings_get_default_value() APIs.
https://bugzilla.gnome.org/show_bug.cgi?id=668233
This will get the 'user' value from the database (ie: the one that the user has
control over).
Provide a default implementation that chains to ->read(). That will work for
all of our internal backends which don't have a concept of layering or
lockdown.
The delayed backend implments "user value" by returning anything that's
in the changeset (incuding an explicit NULL) or chaining up otherwise.
We will use this for g_settings_get_user_value().
https://bugzilla.gnome.org/show_bug.cgi?id=668233
The G_ADD_PRIVATE() macro, and the auto-generated get_instance_private()
internal function, should be used conditionally depending on the maximum
allowed version of GLib, as defined by the GLIB_VERSION_MAX_ALLOWED
pre-processor symbol.
This allows generating code that can be compiled in projects that wish
to use an older API version of GLib through the use of the
GLIB_VERSION_MAX_ALLOWED symbol.
https://bugzilla.gnome.org/show_bug.cgi?id=710133
Prevent a crash in the case that gvdb_table_list() returns NULL (ie:
because a schema has no keys).
Stop a memory leak caused by pointlessly stealing keys from a hashtable
(after we quarked them already).
Stop allocating an extra entry at the end of an array for a terminator
(that we never wrote anyway) when all functions using this API refer to
the out-parameter length array.
https://bugzilla.gnome.org/show_bug.cgi?id=711016
Ignore the keyfile being deleted (ie: by the user) instead of reporting
it to the application as all values being reverted back to their
originals.
https://bugzilla.gnome.org/show_bug.cgi?id=637956
Support the 'extends' attribute that has been supported by the compiler
for a long time by doing three things:
- when creating a schema that extends another schema, lookup that other
schema
- when looking up keys and we can't find them in the schema, check
(recursively) in the 'extends' schema
- when listing all keys in a schema, also visit the extends schemas,
but take care to avoid duplicates caused by overrides
Extend the testsuite to verify that it works.
https://bugzilla.gnome.org/show_bug.cgi?id=645453
g_settings_list_schemas() and g_settings_list_relocatable_schemas() are
now deprecated.
This will allow listing off schemas on non-default sources and is a
better fit with the new direction the API is going.
https://bugzilla.gnome.org/show_bug.cgi?id=680838
Add an API to read the summary and description from the .xml schema
files.
This will be used by dconf-editor and gnome-tweak-tool.
This API is a bit heavy -- it parses the XML and builds a table. It
also loads gettext domains for translation. It only does these things
if it is used, however, so it will not impact normal applications.
We store the summary/description in a pair of hash tables on the schema
source (which we have a backref to as of a few commits ago). We can't
use a global table because people might want to request summary and
description from non-default sources. We don't want to use per-schema
tables because we'd have to reparse the directory every time (since we
cannot guess which file a schema may have been in).
https://bugzilla.gnome.org/show_bug.cgi?id=668232
Take this private API and make it public along with a boxed type and
ref/unref functions.
Future commits will add accessors with new functionality and some that
allow us to deprecate functions on GSettings itself (such as
g_settings_get_range).
https://bugzilla.gnome.org/show_bug.cgi?id=668232
The way we created the global schema list predates
g_settings_schema_source_new_from_directory() and therefore doesn't use
it.
Update it to use that function, removing some code.
https://bugzilla.gnome.org/show_bug.cgi?id=668232
If a broken (or malicious) remote client calls Open or CommandLine
on a GApplication that does not implement those, return a DBus
error instead of going through and then emitting a warning.
https://bugzilla.gnome.org/show_bug.cgi?id=710885
This code was added for use by the G_FILE_ATTRIBUTE_THUMBNAIL_IS_VALID
file attribute, but may end up being used elsewhere (e.g. in GVfs) as well.
As it’s dealing with untrusted external files, and the non-trivial PNG file
format, this commit adds several test cases to cover valid and invalid PNG
files.
The security model for the thumbnail verification code is that the user’s
cache directory is untrusted, and potentially any PNG file which is passed
to the verifier has been manipulated arbitrarily by an attacker.
This is a follow-up to commit fe7069749f.
https://bugzilla.gnome.org/show_bug.cgi?id=709898
This indicates whether the thumbnail (given by G_FILE_ATTRIBUTE_THUMBNAIL_PATH)
is valid — i.e. to represent the file in its current state. If
G_FILE_ATTRIBUTE_THUMBNAIL_IS_VALID is FALSE (for a normal _or_ failed
thumbnail) it means the file has changed since the thumbnail was generated, and
the thumbnail is out of date.
Part of checking thumbnail validity (by the spec) involves parsing
headers out of the thumbnail .png so we include some (small) code to do
that in a separate file. We will likely want to copy this code to gvfs
to do the same for GVfsFile.
Heavily based on a patch from Philip Withnall <philip.withnall@collabora.co.uk>
who suggested the feature and designed the API.
https://bugzilla.gnome.org/show_bug.cgi?id=709898
It is our intention that memory output streams should operate in two
distinct modes, depending on if a realloc function was provided or not.
In the case that we have a realloc function (resizable mode), we want
the stream to behave as if it were a file that started out empty. In
the case that we don't have a realloc function (fixed-sized mode), we
want the stream to behave as a block device would.
To this end, we introduce two changes in functionality:
- seeking to SEEK_END on a resizable stream will now seek to the end of
the valid data region, not to the end of the allocated memory (which
is really just an implementation detail)
- seeks past the end of the allocated memory size are now permitted,
but only on resizable streams. The next write will grow the buffer
(inserting zeros between).
Some tweaks to testcases were required in order not to break the build,
which indicates that this is an API break, but it seems unlikely that
anyone will be effected by these changes 'in the real world'.
Updates to documentation and further testcases are in following commits.
Based on a patch from Maciej Piechotka <uzytkownik2@gmail.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=684842
Introduce the concept of "fixed" vs. "resizable" streams and document
how g_seekable_seek() works for each case.
We don't include g_seekable_is_fixed_size() at this point because we
don't know if anyone would require it. This may appear in the future if
someone asks for it, however.
https://bugzilla.gnome.org/show_bug.cgi?id=684842
D-Bus versions < 1.6.18 (i.e. all current versions) have a bug with the
path_namespace='/' match rule key. It should conceptually match everything,
but actually matches nothing. This results in no property change (or other)
signals being forwarded to the D-Bus client.
The work-around implemented in GDBusObjectManagerClient is to remove the
path_namespace match key if its value is ‘/’.
For the upstream D-Bus bug, see:
https://bugs.freedesktop.org/show_bug.cgi?id=70799https://bugzilla.gnome.org/show_bug.cgi?id=710726
Move a method from GNotificationBackend into the fdo backend (since it
was only used from here). Remove the accessors for the already-public
(in private header) ->dbus_connect and ->application on
GNotificationBackend.
https://bugzilla.gnome.org/show_bug.cgi?id=688492
g_buffered_input_stream_finalize() is already declared as static in this
gbufferedinputstream.c file, so just remove the redundant declaration.
Signed-off-by: Djalal Harouni <tixxdz@opendz.org>
https://bugzilla.gnome.org/show_bug.cgi?id=710345
Replaced several usages of GError with g_return_val_if_fail() for
developer-only messages. As additional value, it also removes those
messages from the list to translate, simplifying translator's work a
bit.
https://bugzilla.gnome.org/show_bug.cgi?id=569017
Over many years of writing code interacting with subprocesses, a pattern
that comes up a lot is to run a child and get its output as UTF-8, to
put inside a JSON document or render in a GtkTextBuffer, etc.
It's very important to validate at the boundaries, and not say deep
inside Pango.
We could do this a bit more efficiently if done in a streaming fashion,
but realistically this should be OK for now.
We weren't closing the streams after we were done reading or writing,
which is kind of essential. The easy way to fix this is to just use
g_output_stream_splice() to a GMemoryOutputStream rather than
hand-rolling it. This results in a substantial reduction of code
complexity.
A second serious issue is that we were marking the task as complete when
the process exits, but that's racy - there could still be data to read
from stdout. Fix this by just refcounting outstanding operations.
This code, not surprisingly, looks a lot like the "multi" test.
Next, because processes output binary data, I'd be forced to annotate
the char*/length pairs as (array) (element-type uint8). But rather than
doing that, it's *far* simpler to just use GBytes.
We need a version of this that actually validates as UTF-8, that will be
in the next patch.
There are a number of nice things this class brings:
0) Has a race-free termination API on all platforms (on UNIX, calls to
kill() and waitpid() are coordinated as not to cause problems).
1) Operates in terms of G{Input,Output}Stream, not file descriptors
2) Standard GIO-style async API for wait() with cancellation
3) Makes some simple cases easy, like synchronously spawning a
process with an argument list
4) Makes hard cases possible, like asynchronously running a process
with stdout/stderr merged, output directly to a file path
Much rewriting and code review from Ryan Lortie <desrt@desrt.ca>
https://bugzilla.gnome.org/show_bug.cgi?id=672102
This is essentially a commandline implementation of the client-side of
the org.freedesktop.Application D-Bus interface.
It includes support for tab-completion based on desktop files and their
contents.
https://bugzilla.gnome.org/show_bug.cgi?id=704218
The GApplicationCommandLine DBus implementation currently calls
g_dbus_method_invocation_return_value() in its finalize() implementation
only, relying on the object being destroyed after g_object_unref() is
called on it inside g_application_impl_method_call().
While this is usually fine for C applications, when overriding the
command_line vfunc from language bindings, the binding might add extra
references to the object, which might not be released immediately - e.g.
because they're garbage collected, or possibly even leaked. The same
scenario could happen in a C application that decides to keep a
reference to the passed-in GApplicationCommandLine object.
To ensure the CommandLine DBus method always gets a reply after the
invocation of command_line in the primary instance, explicitly send the
message back before dropping our reference to the object.
https://bugzilla.gnome.org/show_bug.cgi?id=708042
It's not difficult to do; not all backends implement it, and for some
it may be difficult to implement query_info_on_read(), so let's just
do both.
https://bugzilla.gnome.org/show_bug.cgi?id=706254
Since it could confuse callers (admittedly who are already violating
a precondition).
Just spotted while adapting some bits of this code for a ssh library.
This commit factors out a function for comparing string suffixes, and at
the same time makes it safe for mime types that are shorter than the
"/*" suffix.
==25418== Invalid read of size 1
==25418== at 0x3C6D0F9D22: __gio_xdg_cache_mime_type_subclass (xdgmimecache.c:848)
==25418== by 0x3C6D09ED8C: g_content_type_is_a (gcontenttype.c:158)
==25418== by 0x34D8031E95: gtk_recent_filter_filter (gtkrecentfilter.c:733)
==25418== by 0x34D802F167: _gtk_recent_chooser_get_items (gtkrecentchooserutils.c:387)
==25418== by 0x34D802D07F: idle_populate_func (gtkrecentchoosermenu.c:1011)
==25418== by 0x34D7A20477: gdk_threads_dispatch (gdk.c:804)
==25418== by 0x3C6C0492F5: g_main_context_dispatch (gmain.c:3065)
==25418== by 0x3C6C049677: g_main_context_iterate.isra.23 (gmain.c:3712)
==25418== by 0x3C6C04972B: g_main_context_iteration (gmain.c:3773)
==25418== by 0x34D7FC2AF4: gtk_main_iteration (gtkmain.c:1262)
==25418== by 0x408EB4: main (in /usr/bin/glade)
https://bugzilla.gnome.org/show_bug.cgi?id=708529
Rather than having lots of obscure platform-based #ifdefs all over
gio, define some macros in gcredentialsprivate.h, and use those to
simplify the rest of the code.
https://bugzilla.gnome.org/show_bug.cgi?id=701482
Sometimes the application doesn't want to autostart a service
when it creates a proxy, but wants the service autostarted when
it makes the first method call. Allow that behavior with a new
flag.
https://bugzilla.gnome.org/show_bug.cgi?id=708828
Fix up a lot of whitespace issues in this file since we're about to do
some pretty serious rewriting here anyway...
Add some fold markers while we're at it.
Change the search path to be a global array of 'DesktopFileDir' structures and
change the 'get' function to an 'ensure' function.
This is just a straight-up refactor. Future patches will expand the
DesktopFileDir structure.
Add a convenient and race-free method of watching local files from the
GLib worker thread.
Without this, the race-free way to create a monitor that dispatches
events to the worker thread looked something like this:
- dispatch an idle to the worker thread
- from the idle, create the monitor and connect signals
- from the original thread, wait (on a cond?) until the worker thread
has finished setting up the monitor
- read the file that you were monitoring
which is just ridiculously complicated...
To use the new API:
monitor = g_local_file_monitor_new_in_worker ("/path/to/some/file",
G_FILE_MONITOR_NONE,
&error);
g_assert_no_error (error);
g_signal_connect (monitor, "changed", G_CALLBACK (callback), NULL);
g_local_file_monitor_start (monitor);
'callback' will run from the GLib worker thread.
This is the reason that the start() call was introduced in the previous
commit. The backends that don't use the start() call will have a very
thin race between creating the monitor and connecting the signal, but
hopefully they will be fixed soon.
These new APIs will be used (at least) from gdesktopappinfo to watch for
changes in the desktop file directories.
https://bugzilla.gnome.org/show_bug.cgi?id=704887
and start using the new start() vcall on the local monitor classes.
I only port inotify because I am uncomfortable making changes to the
other monitor backends without having a way of testing them.
https://bugzilla.gnome.org/show_bug.cgi?id=704887
Stop abusing constructor() to do startup work, adding _start() calls
instead.
The backends themselves still use constructor() although a patch will be
following to also fix inotify.
The reason for using a separate start() call instead of constructed()
will become apparent in future commits.
https://bugzilla.gnome.org/show_bug.cgi?id=704887
During initialisation of a directory monitor with the
G_FILE_MONITOR_WATCH_MOUNTS flag set, GLocalDirectory monitor will add a
UNIX mount watch in case the file notification backend doesn't support
reporting these events for itself.
Unfortunately, it was performing the check incorrectly, resulting in a
monitor always being added.
Fix that, and add the #define for G_LOCAL_DIRECTORY_MONITOR_GET_CLASS()
that was also missing (since the fix depends on it).
https://bugzilla.gnome.org/show_bug.cgi?id=704882
Matthew Barnes noted this on IRC a few days ago. I just had this file
open for other reasons and decided to tweak the docs to make this trap
more clear.
https://bugzilla.gnome.org/show_bug.cgi?id=709301
Don't return children with invalid schemas from
g_settings_list_children() (ie: missing schemas or mismatched paths).
This prevents gsettings list-recursively from crashing when broken
schemas are installed on the system.
https://bugzilla.gnome.org/show_bug.cgi?id=705688
There are some corner cases where using the sync version of read/write
in a thread could cause thread-safety issues. In these cases it's
possible to override the output stream's splice_async() function,
but for input streams one would need to do some acrobatics to
stay thread-safe. Alternatively, some implementations may not even
override their sync read/write functions.
This patch refactors the default splice_async() implementation to
call the sync read and write functions in a thread only when both
async versions are thread-based. When one or both are non-threaded,
it calls the virtual write_async() and read_async() functions of the
involved streams within the same thread.
https://bugzilla.gnome.org/show_bug.cgi?id=691581
Refactor g_output_stream_close_async() into itself and an internal
variant for potential use inside other operations (splice_async).
The internal version must be called between
g_output_stream_set_pending() and g_output_stream_clear_pending().
https://bugzilla.gnome.org/show_bug.cgi?id=691581
Previously, no testcases tested the close flags of
g_output_stream_splice_async. This patch adds tests for that and
also tests various combinations of threaded and non-threaded
GInputStream async reads and GOutputStream async writes.
https://bugzilla.gnome.org/show_bug.cgi?id=691581
In implementing a better g_output_stream_splice_async() and possibly
other situtations it's helpful to know whether the output stream's
write function internally uses threads. If it and the input stream's
read async functions use threads, then the splice function could
spawn a single thread for better efficiency.
This patch adds a function to determine whether an output stream's
g_output_stream_write_async() function internally uses threads.
https://bugzilla.gnome.org/show_bug.cgi?id=691581
In implementing a better g_output_stream_splice_async() and possibly
other situtations it's helpful to know whether the input stream's
read function internally uses threads. If it and the output stream's
write async functions use threads, then the splice function could
spawn a single thread for better efficiency.
This patch adds a function to determine whether an input stream's
g_input_stream_read_async() function internally uses threads.
https://bugzilla.gnome.org/show_bug.cgi?id=691581
Rather than always calling out to g_file_get_path() (which
might block, whatever the documentation might say), postpone
the call until we actually need it.
https://bugzilla.gnome.org/show_bug.cgi?id=708753
g_cancellable_disconnect will wait until any pending "cancelled"
handlers finish. This is useful because disconnecting a handler can have the
side-effect of freeing data that the cancelled handler may rely on.
Unfortunately, the code used to enforce this synchronization between
"cancelled" handlers and g_cancellable_disconnect will also cause
deadlock if the cancelled handler itself calls g_cancellable_disconect.
Obviously, if g_cancellable_disconnect is explicitly called by a "cancelled"
handler, then the "cancelled" handler is shouldering the responsibility
of not using any data that may be freed by disconnection.
Also, g_cancellable_disconnect can be called in unexpected places by
lower layers in the code (for instance as a result of g_source_destroy).
In practice, this means it's easy for deadlocks to inadvertently crop
up when using "cancelled" handlers.
For these reasons, it would be good to fix the deadlock.
This commit prevents the deadlock by allowing foregoing synchronization,
if a pending "cancelled" handler is in the same thread as the
g_cancellabale_disconnnect call.
https://bugzilla.gnome.org/show_bug.cgi?id=705395
In the real_..._async wrapper for GFile.measure_disk_usage, skip the
wrapping of the progress callback in the case that the user gave a NULL
callback to the async function. This is a performance improvement
because the sync version won't have to do continuous sampling of the
clock to issue a call to the wrapper which will then do nothing.
Unfortunately, I made this simplifying assumption when writing the
wrapper, but forgot to actually implement it when making the sync call.
As a result, the wrapper is still called, and invokes the NULL callback,
causing a segfault.
Make sure we pass NULL if the user's callback was NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=707787
Make use of __wgetmainargs() on Windows so that we can get wide char
versions of the argv's that are passed in when this test program is being
invoked. This is necessary as one might enter non-ASCII, such as
CJK characters filenames and/or directories to run the test program
against, so that we can process the name(s) and pass the proper
UTF-8-encoded name(s) of the files/directories that is being tested.
https://bugzilla.gnome.org/show_bug.cgi?id=707787
It turns out that although dirent is available on mingw32 (where the
code was originally tested), it is not usable from MSVC.
Avoid portability problems by just using GDir.
Also, be careful about ensuring that we utf8-format filenames in our
error messages, and leave out the "file://" component since the strings
we're displaying are not URIs (and we don't want to make them URIs since
the extra escaping would reduce legibility).
Thanks to Chun-wei Fan <fanchunwei@src.gnome.org> for portions of this
patch and for reviews.
https://bugzilla.gnome.org/show_bug.cgi?id=707787
