We already have start, stop and is_active methods, but turning it
into a real property is useful for a few reasons:
- it allows us to bind the property to an UI or a setting
- it allows us to get notified when the state changes
- it allows us to instantiate objects directly in the stopped state
https://bugzilla.gnome.org/show_bug.cgi?id=752089
Also add g_app_info_get_fallback_for_type() and
g_app_info_get_recommended_for_type() as proxies for
g_app_info_get_all_for_type(), until gcontenttype support is improved.
This code was out of date with current coding practices.
Nowadays it's common to receive file descriptors over environment
variables from other processes like systemd. The unit files that
control these file descriptors are configurable by sysadmins.
It is not (necessarily) a programmer error when g_socket_details_from_fd()
is called with a file descriptor that is not a socket. It can also
be a system and/or configuration error.
https://bugzilla.gnome.org/show_bug.cgi?id=746339
In 4e7d22e268, deleting the file was moved
after the assertion which checks for the changed event that results from
it being deleted. This is the wrong way around and makes the assertion
fail.
Move the deletion back up before we check the condition. delete_app is
no longer an idle callback so it can be made void. The change
notification might come in when the loop isn't running now, so don't try
to quit if it isn't running. In this case we'll wait for the three
second timeout and the test will still pass.
https://bugzilla.gnome.org/show_bug.cgi?id=751737
When a task is cancelled, we want to move it to the front
of the queue - our sort function does that for us, but there
is no need to resort the entire queue here, we can just
move the one item and be done with it. This uses just-introduced
threadpool api for this purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=751160
We set G_ANALYZER_ANALYZING to 1 when clang supporting static analyzing before,
but this will cause compilation error when -Werror=return-type is used and the
static analyzer is not in use because g_error static function only has
__attribute__((analyzer_noreturn)), which is useless for normal compilation.
https://bugzilla.gnome.org/show_bug.cgi?id=741901
We already do this in the normal case, might as well support it for the
dynamic type module case as well. This prevents seeing a warning when not
using the get_instance_private() in the dynamic type.
Make sure to initialize the notification backend in
g_application_withdraw_notification() the same way as is done in
g_application_send_notification().
This makes it possible for an app to withdraw notifications it has sent
in a previous execution of the application.
https://bugzilla.gnome.org/show_bug.cgi?id=750625
We need to be more careful when we try to assign values to gpointers, so
that means we have to assign the value to the properly-dereference
gpointer, so that the assigned value will be retained after the function
returns. This code will be dropped soon, but it is done for XP
compatibility's sake for 2.44.
Should fix the issue reported in bug 730352 comment #24.
For performance reasons we should always try to send or
receive our messages first and only wait for more space
or data to become available if we get an EAGAIN (and
are in blocking mode).
https://bugzilla.gnome.org/show_bug.cgi?id=751122
The documentation was not very clear about the handling
of the '#' comment markers. State clearly how these are
handled by the getter and the setter.
https://bugzilla.gnome.org/show_bug.cgi?id=479730
Using the register keyword triggers warnings on noteworthy compilers
(clang), since it's deprecated in C++ and at danger of being removed
from the language. There is no reason to use it since it isn't 1980
anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=750918
This can be handy when you want to change the sense of a toggle
in the UI without rewriting the underlying logic. Currently, this
is just exposed as a construct-only property. We may add a
convenience wrapper or a special !property syntax for this later.
https://bugzilla.gnome.org/show_bug.cgi?id=728489
This is the right thing to do for the "a session is a user-session"
model implemented in dbus 1.9.14, which is described in
<http://lists.freedesktop.org/archives/dbus/2015-January/016522.html>.
It also resembles sd-bus' behaviour, although sd-bus will only try
kdbus and XDG_RUNTIME_DIR/bus, and never runs dbus-launch.
On systems following the more traditional "a session is a login-session"
model, X_R_D/bus won't exist, so it is harmless to check for it before
falling back to X11 autolaunching. Again, this matches the behaviour
of current libdbus and sd-bus versions.
Now that we do this, g_test_dbus_unset() needs to clear XDG_RUNTIME_DIR
as well as everything else.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=747941
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
This only alters what happens if we specifically connect to
"autolaunch:", for instance via "DBUS_SESSION_BUS_ADDRESS=autolaunch:".
We will still potentially try other platform-specific things if
DBUS_SESSION_BUS_ADDRESS is unset. There are currently no other
platform-specific things, so there is no practical difference yet,
but I'm about to add a more-preferred fallback path before autolaunch.
This matches libdbus' behaviour and the D-Bus Specification, in which
the autolaunch: transport specifically means X11 autolaunch
(as implemented by "dbus-launch --autolaunch") on Unix, or a
shared-memory-based protocol on Windows. Other platform-specific
transports or default/fallback modes, including launchd on Mac OS X
and XDG_RUNTIME_DIR/bus on Unix, are not part of "autolaunch:".
It's rather unfortunate that the same name means two different
platform-specific mechanisms, specific to different platforms -
if they were added today I'd call them x11: and windows-shm: or
something - but it's been like this since 2007 so it's too late now.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=747941
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Normally, recent PCRE behaves as if certain patterns were replaced
by a more "possessive" pattern that gives the same answer for normal
regex matching, but is more efficient. However, the modified pattern
produces fewer results under DFA. If we want the full set of results
we have to apply PCRE_NO_AUTO_POSSESS, and that's a compile-time flag.
This currently only affects a system PCRE, but would also work fine for
an internal PCRE 8.34 or later if the embedded copy is updated.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=733325
Reviewed-by: Christian Persch <chpe@gnome.org>
