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
Add a pair of functions to make it easier to do simple string matching.
This will be useful for use with things like GtkSearchBar and will also
be the basis of the searching done by the (soon to appear)
g_desktop_app_info_search()
https://bugzilla.gnome.org/show_bug.cgi?id=709753
When the source id reaches G_MAXUINT (just prior to overflow), we
record the existing source ids to prevent reassigning them. As we are
about to assign G_MAXUINT to the triggering source, that id should be
added as well.
https://bugzilla.gnome.org/show_bug.cgi?id=710002
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.
GBindingTransformFunc called its arguments "source_value" and
"target_value", but in the transform_from function of a bidirectional
binding, "source_value" comes from the target object, and
"target_value" comes from the source object, which quickly gets
confusing if you need to use g_binding_get_source(), etc, in the
function.
Of course developers can call their transform function arguments
whatever they want, but many will copy from the headers/docs to start
out, so use less confusing names here ("from_value" and "to_value").
Also, fix the documentation to describe the bidirectional case
correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=709440
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
