We don't use this for anything inside of GApplication yet, but Gtk is
about to start using it to find various bits of the application (such as
its menus, icons, etc.).
By default, we form the base path from the application ID to end up with
the familiar /org/example/app style.
https://bugzilla.gnome.org/show_bug.cgi?id=722092
This is not a functional change, as the hints field is static and hence
automatically initialised to zero — which happens to be what AF_UNSPEC
and the unspecified protocol are defined as. However, it’s best to be
explicit about this, in case AF_UNSPEC is _not_ defined as zero.
https://bugzilla.gnome.org/show_bug.cgi?id=732739
I recently needed to nul-terminate the returned buffer, and I wasn't
sure if g_input_stream_read() does that or not. I've checked
glocalfileinputstream.c, which calls read(2) which doesn't nul-terminate
the buffer. So I assume it's the same behavior for all GInputStream
subclasses.
https://bugzilla.gnome.org/show_bug.cgi?id=732704
When using this API, I wasn't sure what the cancellable does. I think
it's generally desirable to kill the subprocess if the wait operation is
cancelled, since in this case the application is no longer interested by
the subprocess.
https://bugzilla.gnome.org/show_bug.cgi?id=732704
A critical message is printed when a parameter of g_file_equal() is not
a GFile. When we read the documentation before this commit, we can think
that passing NULL or another type than GFile is allowed, but it is not
the case.
Another option is to allow NULL parameters. But for consistency with
e.g. g_str_equal(), it's probably better to keep the code as is.
https://bugzilla.gnome.org/show_bug.cgi?id=732357
- g_subprocess_launcher_spawn() and spawnv(): there is no other way
AFAIK to create a GSubprocess from a launcher. So these
functions are not "convenience helper".
- annotate optional arguments for g_shell_parse_argv().
- other trivial fix
https://bugzilla.gnome.org/show_bug.cgi?id=732357
Document that giving %NULL for the activate handler is supported since
GLib 2.40. We documented this on GSimpleAction itself (where the
default handler functionality is implemented) but expecting the user to
dig that up is asking a bit much.
Also, add some more explicit documentation about the conditions under
which each field is expected to be filled in.
https://bugzilla.gnome.org/show_bug.cgi?id=732429
This property has been deprecated for three years after only having
existed for one. We've wanted to reuse the name for all that time, so
let's try to actually remove it now and see if we can get away with it.
https://bugzilla.gnome.org/show_bug.cgi?id=732102
Instead of closing the sockets explicitly, let them close themselves
when their final reference is dropped. This makes use of
g_socket_listener_add_socket() more natural.
https://bugzilla.gnome.org/show_bug.cgi?id=732107
This is quite important, as it means you can safely let the GSocket drop
out of scope while maintaining a reference to the GSource, and the
socket will remain open. That means fewer closure structures, simpler
code, and fewer allocations.
https://bugzilla.gnome.org/show_bug.cgi?id=732081
'folder' is the name of the folder icon in the incon naming spec,
and the Adwaita icon theme doesn't include an inode-directory icon.
This fixes folders appearing as generic file in the file chooser.
https://bugzilla.gnome.org/show_bug.cgi?id=731996
The stdout FD passed to dbus-daemon is propagated to all its child
processes, such as service activated processes. If we close the FD after
reading the bus address from the daemon, any child process which
subsequently writes to stdout (e.g. for logging) will get a SIGPIPE and
explode.
Instead of closing the stdout FD immediately after dbus-daemon has
spawned, keep it open until the daemon is killed.
https://bugzilla.gnome.org/show_bug.cgi?id=732019
Availability of the g_nextstep_settings_backend_get_type() prototype
is controlled by HAVE_COCOA in gsettingsbackendinternal.h and the
actual implemenation by OS_COCOA in Makefile.am. Therefore, the
giomodule.c call to that function should also be protected by a COCOA
token rather than an CARBON token (cocoa and carbon are independent
autoconf tests).
https://bugzilla.gnome.org/show_bug.cgi?id=731425
GResolver doesn't do full validation of its inputs, so in some of
these tests, the fact that we were getting back
G_RESOLVER_ERROR_NOT_FOUND is because the junk string was getting
passed to an upstream DNS resolver, which returned NXDOMAIN. But if
there's no network on the machine then we'd get
G_RESOLVER_ERROR_INTERNAL instead in that case.
Windows does not like g_unlink() to be called on files whose file
descriptor is still open, so doing that would cause a permission
denied error. Since the fd is not used in that function after
acquiring the temp file, close it earlier before
g_file_set_contents(), so that it can complete successfully.
This fixes a number of GTK+ tests on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=719344
- GSubprocessLauncher exists since 2.40, not 2.36
- more logical order for g_markup functions
- fix short description of GMarkup
- GMarkupParser: specify that some parameters are NULL-terminated.
- g_string_new (NULL); is possible.
- other trivial fixes.
https://bugzilla.gnome.org/show_bug.cgi?id=728983
* removed passing GError to ensure_input_padding() function
- it was necessary before commit 3e5214c15c
when we used GData*Streams and GMemoryInputStream with
g_seekable_seek() - now it's useless,
* removed checking return value of ensure_input_padding()
function - in previous implementation (like above)
g_seekable_seek() could return FALSE - now it's always TRUE,
* removed passing GError to g_memory_buffer_read_*() functions
and checking returned value - it also has been inherited after
old implementation with g_data_input_stream_read_*() functions
- now it's also useless
* cleaned up code formatting,
https://bugzilla.gnome.org/show_bug.cgi?id=729875
Expand the functionality of g_desktop_app_info_set_desktop_env() to
include the possibility of passing strings containing ':' characters (as
some apps, such as gnome-session, are directly passing the value of
XDG_CURRENT_DESKTOP). At the same time, deprecate it, since now we get
the list from the environment variable for ourselves.
Modify the checks in g_desktop_app_info_get_show_in() to deal with
multiple items listed in XDG_CURRENT_DESKTOP. For example, if we find
that we have
XDG_CURRENT_DESKTOP=GNOME-Classic:GNOME
and a desktop file contains:
OnlyShowIn=GNOME
then we will show this file because of the fallback to GNOME. If the
file _also_ contains the line:
NotShowIn=GNOME-Classic
Then we will not show it, because GNOME-Classic comes before GNOME in
XDG_CURRENT_DESKTOP.
https://bugzilla.gnome.org/show_bug.cgi?id=729813
GDummyTlsConnection didn't implement the "interaction" property,
meaning you'd get warnings if you tried to set it while creating a
GTlsConnection when using the dummy backend. (Of course, trying to
create the GTlsConnection will fail anyway, but it ought to fail
without hitting any g_warnings.)
It was previously possible for GThreadedResolver to return an empty list
and no error in response to a g_resolver_lookup_by_name() call, if it
happened that all the addresses returned by getaddrinfo() could not be
converted from native addresses to GSocketAddresses.
Fix that by setting a G_RESOLVER_ERROR_NOT_FOUND if the returned list is
empty.
https://bugzilla.gnome.org/show_bug.cgi?id=728776
The documentation previously wasn’t clear about whether the GResolver
methods could return an empty list and no error. On balance, this seems
like a bad idea, and GResolver should commit to always return a
non-empty list, or an error (which should be G_RESOLVER_ERROR_NOT_FOUND
if the list would otherwise be empty).
https://bugzilla.gnome.org/show_bug.cgi?id=728776
ddf82a25 removed the use of non-literal format strings from
gthreadedresolver.c, but left the "#pragma GCC diagnostic ignored
-Wformat-nonliteral" behind.
These did show up in the html. Since symbol names are checked for a
trailing plural s when generating the docs, the links stay functional
after removing these comments.
https://bugzilla.gnome.org/show_bug.cgi?id=728380
Redo the code for type-based selection of applications (all,
recommended, default, fallback) based on the new DesktopFileDir
structures that we introduced last cycle.
At the same time, we expand the functionality to add support for the new
features of the specification:
- moving ~/.local/share/applications/mimeapps.list to ~/.config/
- per-desktop default applications (via XDG_CURRENT_DESKTOP)
- sysadmin customisation of defaults (via /etc/xdg/mimeapps.list)
- deprecation of the old defaults.list, favouring the use of
/usr/share/applications/mimeapps.list (or gnome-mimeapps.list) to
accomplish the same
We modify the mimeapps testcase to check for mimeapps.list having been
created in XDG_CONFIG_HOME instead of XDG_DATA_HOME.
The modification is a net reduction of code (due to less duplication in
bookkeeping). It is also an increase in performance and reduction in
memory consumption (due to simplified data structures). Finally, it
removes the stat-based timestamp checking in favour of the
GFileMonitor-based approach that was already being used in the
implementation of DesktopFileDir (in order to know if we had to rescan
the desktop files themselves).
https://bugzilla.gnome.org/show_bug.cgi?id=728040
We currently assume that setting an application as the default will take
it to the front of the list of supported applications for a given type,
but this is not necessarily true.
Check instead that the application is actually set as default.
https://bugzilla.gnome.org/show_bug.cgi?id=728040
Set XDG_DATA_DIRS to make sure we don't use /usr/share from the
appmonitor test. We will soon throw a warning if we find defaults.list,
so make sure we don't open ourselves up to that if there is one on the
system.
https://bugzilla.gnome.org/show_bug.cgi?id=728040
The desktop file for myapp3 didn't declare support for image/png, but
the testcase expects it to be recommended on the basis of it being the
default app according to defaults.list.
This will not work in the future -- we will only list apps that actually
support the filetype in question, unless they've been explicitly added
as associations.
https://bugzilla.gnome.org/show_bug.cgi?id=728040
The app launch context may just not support startup notification,
in which case, g_app_launch_context_get_startup_notify_id() will
return NULL.
Failure to take this into account leads to criticals like this:
gnome-session[8489]: GLib-CRITICAL: g_variant_new_take_string: assertion 'string != NULL' failed
gnome-session[8489]: GLib-CRITICAL: g_variant_new_variant: assertion 'value != NULL' failed
gnome-session[8489]: GLib-CRITICAL: g_variant_get_type: assertion 'value != NULL' failed
gnome-session[8489]: GLib-CRITICAL: g_variant_type_is_subtype_of: assertion 'g_variant_type_check (type)' failed
https://bugzilla.gnome.org/show_bug.cgi?id=728066
Add G_DBUS_ERROR codes for:
* org.freedesktop.DBus.Error.UnknownObject
* org.freedesktop.DBus.Error.UnknownInterface
* org.freedesktop.DBus.Error.UnknownProperty
* org.freedesktop.DBus.Error.PropertyReadOnly
These were discussed on the dbus mailing list
and introduced in the following libdbus commit:
2c34514620c4b79ea4ec71d1db583379138d01ac
https://bugzilla.gnome.org/show_bug.cgi?id=727900
g_tls_certificate_list_new_from_file() was supposed to ignore non-PEM
content, but it accidentally required that there not be anything after
the last certificate. Fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=727692
Make sure that the @ sign is inside the authority part before attempting
to parse the userinfo. We do this by checking if the @ sign comes before
any of the possible authority delimiters.
Add unit test to verify parsing of ftp://ftp.gnome.org/start?foo=bar@baz
https://bugzilla.gnome.org/show_bug.cgi?id=726040
Rather than having special code in gsocket.c, handle Winsock errors
along with other Win32 errors in gioerror.c
Also, reference g_win32_error_message() from the
g_io_error_from_win32_error() docs, and update the
g_win32_error_message() docs to clarify that it works with Winsock
error codes too.
Map EPROTONOSUPPORT, ESOCKTNOSUPPORT, EPFNOSUPPORT and EAFNOSUPPORT to
G_IO_ERROR_NOT_SUPPORTED in g_io_error_from_errno(). (GSocket's
socket_io_error_from_errno() already did this with the corresponding
Winsock errors.)
Also map EOPNOTSUPP, which on Linux is the same as ENOTSUP, but may
not be on other platforms.
Also, rewrite the EAGAIN/EWOULDBLOCK section to use the simpler idiom
used by EEXIST/ENOTEMPTY and (now) ENOTSUP/EOPNOTSUPP.
Use #GVariant instead of GVariant.
g_notification_add_button_with_target,
g_notification_set_default_action_and_target:
Replace 'format_string' with 'target_format'.
g_notification_set_default_action_and_target_value:
Remove paragraph that apparently had been accidentally copied from
g_notification_set_default_action_and_target.
https://bugzilla.gnome.org/show_bug.cgi?id=727123
In the event that a GSettings object is being destroyed just as a change
signal is being delivered, the destroying thread will race with the
dconf worker thread for acquiring the lock on the GSettingsBackend.
If the signalling thread gets there first then the destroying thread
will block on the lock. The signalling thread adds a reference to the
GSettings object that is being destroyed and releases the lock. The
idea is that this should prevent the GSettings object from being
destroyed and thus maintain its entry in the list. Unfortunately, the
weak reference notify function is already running and as soon as we
release the lock, the list entry is removed.
The signalling thread crashes.
This bug is indicative of a serious problem encountered in many
situations where GObject instances are touched from multiple threads.
Ideally, we will move to a place where g_object_ref() is not called at
all on the GSettings object from the dconf worker thread and instead, a
dispatch will be done without holding a reference (similar to how
GAppInfoMonitor presently works). This would also prevent the
unfortunate case of someone dropping what they assume to be the last
reference on a GSettings object, only to have an already-pending signal
delivered once they return to the mainloop, crashing their program.
Making this change for GSettings (with multiple instances per thread,
the possibility of multiple backends and each instance being interested
in different events) is going to be extremely non-trivial, so it's not a
change that makes sense at this point in the cycle.
For now, we can do a relatively small and isolated tweak so that we
never access the list except under a lock. We still perform the bad
pattern of acquiring a ref in a foreign thread which means that we still
risk delivering a signal to a GSettings object that the user has assumed
is dead (unless they explicitly disconnect their signal handler). This
is a problem that we already had, however.
https://bugzilla.gnome.org/show_bug.cgi?id=710367
Change the order of the arguments on the (internal) keys_changed callback in
GSettingsListenerVTable.
This means that all functions in the table now fit the following signature:
void (* f) (GObject *target,
GSettingsBackend *backend,
const gchar *name_or_path,
gpointer origin_tag,
const gchar * const *names);
allowing the possibility of arguments ignored at the end.
This allows us to simplify our dispatch-to-thread code in GSettingsBackend,
making it a bit less generic.
So far, this should be a straight refactor.
https://bugzilla.gnome.org/show_bug.cgi?id=710367
The _finish functions for GUnixVolume _mount and _eject functions were
never implemented, having been simply stubbed out as 'return TRUE;'.
Implement them.
https://bugzilla.gnome.org/show_bug.cgi?id=724916
The existing code is buggy and now that we have GSubprocess, we should just use
it instead, allowing for some substantial reduction in complexity.
https://bugzilla.gnome.org/show_bug.cgi?id=724916
As of e6af432, g_content_type_get_symbolic_icon() returns non-symbolic
fallbacks. Thus, we can't append another symbolic icon to the fallbacks.
The special case was a bit of a hack anyway. It was only applied to
themed icons and there was no generic fallback for mime types that are
not folders.
https://bugzilla.gnome.org/show_bug.cgi?id=726046
We need to have these in BUILT_SOURCES so that 'make' knows to generate them
before attempting to compile other .c files in the same directory (since some
of these files include the header).
Should fix up remaining issues about partial versions of this file being
included under parallel builds.
https://bugzilla.gnome.org/show_bug.cgi?id=725891
