In order to enrich information displayed by GApplication command line
handling when --help is invoked, 3 new methods are proposed:
. g_application_set_option_context_parameter_string
. g_application_set_option_context_summary
. g_application_set_option_context_description
Those methods interact with the GApplication's internal GOptionContext
which is created for command line parsing in g_application_parse_command_line.
(please refer to the GOptionContext class for more information about option
context, parameter string, summary and description.)
To illustrate the 3 methods, an example is provided:
. gapplication-example-cmdline4.c
to suppress a compiler error with stricter warnings enabled (GCC):
gdbus-test-codegen.c: In function ‘on_handle_get_self’:
gdbus-test-codegen.c:403:26: error: format ‘%p’ expects argument of type
‘void *’, but argument 2 has type ‘GThread * {aka struct _GThread *}’
[-Werror=format=]
s = g_strdup_printf ("%p", g_thread_self ());
https://bugzilla.gnome.org/show_bug.cgi?id=792099
The GSocketListener::event signal has a type of GSocketListenerEvent,
which is an enum. However, the vfunc signature had a pointer, with
different sizing requirements. Given the alignment and prompostion
of some systems, you may still get the same call-site layout, but
that is not guaranteed.
This fixes the parameter to have the proper enumeration.
https://bugzilla.gnome.org/show_bug.cgi?id=791906
Add filesystem magic numbers found in statfs(2) manual page. Filesystem
magic numbers that are not available from the manual page are copied
from Linux source code.
configfs is found in fs/configfs/mount.c, macro CONFIGFS_MAGIC.
fusectl is found in fs/fuse/control.c, macro FUSE_CTL_SUPER_MAGIC.
rpc_pipefs is found in net/sunrpc/rpc_pipe.c, macro RPCAUTH_GSSMAGIC.
https://bugzilla.gnome.org/show_bug.cgi?id=754634
Previously, we waited an arbitrary 100ms or 200ms and then asserted
that the events had happened, but that might fail if the machine is
slow or heavily loaded.
We still wait for an arbitrary time for negative tests (asserting
that no more signals are received) because we don't have any way
to do better here.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884661https://bugzilla.gnome.org/show_bug.cgi?id=791744
In autotools this same check reads:
AS_IF([test $glib_native_android != yes]
with glib_native_android being defined as:
case $host in
*android*)
glib_native_android="yes"
;;
*)
glib_native_android="no"
;;
esac
This is needed to be able to compile on OSX.
https://bugzilla.gnome.org/show_bug.cgi?id=791460
Signed-off-by: Nirbheek Chauhan <nirbheek@centricular.com>
This patch considers generic icon names also when icon names
are searched based on content type. Without this fix only
non-generic icon names are found. This results in no icons
for pdf and jpeg files in the file selection dialog.
This is discussed in
https://bugzilla.gnome.org/show_bug.cgi?id=788936
New test to make sure we exercise the code paths in gdesktopappinfo.c
that get triggered when g_desktop_app_info_launch_uris_with_spawn()
is used (i.e. unknown app ID, no session bus), both for when either
a single URI or multiple ones are expected by the application.
https://bugzilla.gnome.org/show_bug.cgi?id=791337
If an application calls g_app_info_launch_uris() with a GList that includes
NULL values in some of its data members, and GIO ends up internally calling
g_desktop_app_info_launch_uris_with_spawn() for whatever reason (e.g. no
D-Bus session available), expand_macro() will crash due to the invalid data.
As this is considered a programmer error, use g_return_val_if_fail() in those
situations to prevent the crash from happening, but printing a warning anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=791337
This list will be modified in-place when calling expand_macro(), so pass a copy
of it instead the original pointer, that is supposed to be an input parameter
only for g_desktop_app_info_launch_uris_with_spawn().
https://bugzilla.gnome.org/show_bug.cgi?id=791337
In MacOS the file selection dialog does not show folder icons.
With this fix the folder icons are shown. The bug is described
in:
https://bugzilla.gnome.org/show_bug.cgi?id=788936
This bug fix is only partial, because this fix is only the
last resort when no mime information is available.
The thumbnail attributes would previously only be set if thumbnail::path
was included in the query — so querying for just thumbnail::is-valid
would return no results.
This fixes the behaviour of
gio info -a thumbnail::is-valid ./some-file.png
vs
gio info -a thumbnail ./some-file.png
The first command would previously list nothing. The second would
previously list a thumbnail::path and thumbnail::is-valid.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=791325
Putting a <!-- --> in plural<!-- -->s was an old hack used to fix
linking the symbol with gtk-doc when gtk-doc didn’t know about plural
forms. gtk-doc does now know about plural forms, so the hack can be
removed.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
g_variant_get_normal_form() doesn’t necessarily return a floating
GVariant, so we have to take, rather than sink, the ref.
This fixes a lot of leaks with gdbus-codegen-generated code.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=741167
When using gdbus-codegen to produce generated code for a method with
an out parameter with a signature like 'as', make sure to include
an "(array)" annotation for that parameter.
(Reworked by Philip Withnall to improve code formatting.)
https://bugzilla.gnome.org/show_bug.cgi?id=741167
Apparently Solaris defines statbuf fields as long when Linux doesn’t, in
some cases. Cast down to the type expected by the printf() format
placeholder.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=749652
Two of the vfuncs in GMountOperation need some annotations for their
element types and array sizes, otherwise g-ir-scanner comes up with
nonsense output.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=773980
Bug #786580 triggered this warning to show up in the appinfo tests if
run on a machine where no terminal except xterm is installed (for
example, a build machine). Since we didn’t warn before if xterm but no
other terminals were installed, it seems reasonable to downgrade the
warning to a debug message.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790914
If we can’t convert the inotify event mask into a GFileMonitorEvent enum
value, don’t propagate it to GLocalFileMonitor, since it hits an
assertion failure in that case.
This should no longer be possible since the previous commit to ignore
IN_Q_OVERFLOW events, but we might as well change this just in case
other bugs crop up in event mask handling.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776147
There’s not much we can do about them, and if they go unhandled, they
can propagate through to g_file_monitor_source_handle_event() and cause
assertion failures due to not mapping to a GFileMonitorEvent.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776147
That event is deprecated, and the kqueue backend can’t provide enough
information to go alongside the event (i.e. the name of the new file).
Use G_FILE_MONITOR_EVENT_DELETED instead.
Quite disappointed in the kqueue documentation for this: I cannot find a
single piece of documentation or example about how NOTE_RENAME is
supposed to communicate the new name of the file.
If it turns out that this is possible, the code can be amended again in
future. At least now it doesn’t abort.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776147
While gio module extension is loaded a new GProxyResolverPortal is
created to query whether it's supported. We always return FALSE when not
aunder flatpak, so we don't need to connect to the session bus in that
case. Add a helper ensure_resolver_proxy() that returns TRUE when the
proxy is created and use it in is_supported() instead of creating the
proxy unconditionally in the instance initialization.
https://bugzilla.gnome.org/show_bug.cgi?id=790894
fstype is a const char*, and is passed to
g_file_info_set_attribute_string(), which takes a copy of it. There’s no
need to g_strdup() the FS type from various statfs/statvfs buffers
beforehand, given that the buffers are valid for the duration of this
function.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=679347
This adds g_file_load_bytes() to make it more convenient to
load the contents of a GFile as GBytes.
It includes a special casing for gresources to increase the
chances that the GBytes directly references the embedded data
instead of copying to the heap.
https://bugzilla.gnome.org/show_bug.cgi?id=790272
In the vast majority of cases, we can avoid temporary
allocations for paths in g_resources_enumerate_children().
In the case we need to add a suffix "/", we can usually just
build the path on the stack. In other cases, we can completely
avoid the strdup, which appears to only have been added for
readability. If the path is really long, we fallback to doing
what we did before, and use g_strconcat().
In the case of Builder, this saved 5.3mb of temporary
allocations in the process of showing the first application
window.
https://bugzilla.gnome.org/show_bug.cgi?id=790275
Previously, the path canonicalization for resources had liberal use of
strlen() and memmove() while walking through the path. This patch avoids
any secondary strlen() and removes all use of memmove().
A single allocation is created up front as we should only ever need one
additional byte more than then length of the incoming path string.
To keep the implementation readable, the mechanics are kept in external
functions. memrchr() was not used due to its lack of portability.
This is faster in every test case I've tested. Paths that contain
relative ../ have the most speedup.
https://bugzilla.gnome.org/show_bug.cgi?id=790310
