If someone explicitly calls g_application_quit() then don't attempt to
drain the mainloop of remaining sources.
This allows applications with 100% CPU utilisation to quit reliably.
https://bugzilla.gnome.org/show_bug.cgi?id=744876
We install win32-software/autorun.exe (as test data for mime scanning)
only on UNIX builds, so don't attempt to chmod it on 'make install'
unless we're on UNIX.
This is pure read-only access to an external struct
so void warnings for people calling it from const
contexts such as accessors
https://bugzilla.gnome.org/show_bug.cgi?id=745068
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
switching to the old macros boilerplate to G_DECLARE_*
a lot of warnings start to pop when *_IS_A_* or such are
called from a const context.
Fix this by taking const pointers as parameters
https://bugzilla.gnome.org/show_bug.cgi?id=745068
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
I love Emacs keyboard macros, used them to convert the list of
defines cleverly into a list of tests, then iterated and filled in
the necessary constructor arguments.
- It's not sufficient, there are other bare array types
like guint8, gdouble, etc.
- Other types like GVariant* always come as pointers, whereas
there's a rather fundamental distinction between "gchar" and
"gchar*" that has been signified to C programmers for 30+ years via
the '*' character, and we're hiding that.
https://bugzilla.gnome.org/show_bug.cgi?id=744747
The g_autoptr() being associated with the type name works out really
well for things like GHashTable. However, it's a bit more awkward to
associate with "gchar". Also because one can't use "char".
Similarly, there are a lot of other "bare primitive array" types that
one might reasonably use.
This patch does not remove the autoptr for "gchar", even though I
think it's rather awkward and strange.
Also while we're here, add a test case for the cleanup bits.
https://bugzilla.gnome.org/show_bug.cgi?id=744747
After ::shutdown, run the mainloop until all pending activity is
handled, before returning from run().
Among other things, this gives a chance for destroyed windows to be
properly withdrawn from the windowing system.
https://bugzilla.gnome.org/show_bug.cgi?id=744876
This is *significantly* more pleasant to use from C (while handling
errors and memory cleanup).
While we're here, change some ugly, leaky code in
tests/desktop-app-info.c to use it, in addition to a test case
in tests/file.c.
https://bugzilla.gnome.org/show_bug.cgi?id=661554
g_application_bind_busy_property() had the restriction that only one
property can be bound per object, so that NULL could be used to unbind.
Even though this is enough for most uses, it is a weird API.
Lift that restriction and add an explicit unbind function.
https://bugzilla.gnome.org/show_bug.cgi?id=744565
Add an implementation of non-thread-emulated async close of a GIOStream
if either of the underlying stream objects support it.
This prevents us from calling close() functions from another thread on
an object that may not be expecting that. It also allows us to skip the
thread entirely in case our objects support a pure async close.
https://bugzilla.gnome.org/show_bug.cgi?id=741630
Add an internal helper to find out if close_async() is implemented via
threads using the default implementation in the base class.
We will use this to decide if we should do a 'pure async' close of a
GIOStream or not.
https://bugzilla.gnome.org/show_bug.cgi?id=741630
delayed_close_free() calls g_object_unref() on a variable that is
expected to possibly contain NULL (as indicated by the fact that the
NULL case is handled in my_slow_close_output_stream_close_async()).
This is dead code right now (due to a bug in GDBus), which is why it
isn't actually causing a failure. It should still be fixed, however.
https://bugzilla.gnome.org/show_bug.cgi?id=743990
GApplication set the prgname to the application's id when it was running
in service mode. This broke with the addition of new --app-id option,
because g_set_prgname() was called before parsing the options. Calling
it after option parsing doesn't work, because GOptionContext sets
prgname to argv[0] unconditionally.
Instead of changing the semantics of GOptionContext, simply remove this
functionality from GApplication. It is very unusual to have the prgname
set to the app id instead of the binary's name and might confuse people
when looking at logs etc.
When overriding local_command_line() from a subclass,
g_option_context_parse() might never be invokded. Thus, continue setting
the prgname to argv[0] in GApplication.
https://bugzilla.gnome.org/show_bug.cgi?id=743933
Balancing g_application_{un,}mark_busy() is non-trivial in some cases.
Make it a bit more convenient by allowing to bind multiple boolean
properties (from different objects) to the busy state. As long as these
properties are true, the application is marked as busy.
https://bugzilla.gnome.org/show_bug.cgi?id=744565
This would allow bindings to use _get_option_group() functions, which
would then allow them to use GOption parsing.
This also adds introspection annotations to
g_option_context_add_group(), g_option_context_set_main_group() and
g_option_context_get_main_group().
https://bugzilla.gnome.org/show_bug.cgi?id=743349
Despite linked lists being a fairly fundamental computer science
concept, some developers insist on using:
g_list_length (list) > 0
to determine whether a list is non-empty, rather than using:
list != NULL
Add a comment to the documentation for g_list_length() and
g_slist_length() pointing out the better alternative in the hope that it
will prevent some of this abuse.
https://bugzilla.gnome.org/show_bug.cgi?id=741024
