Also add a 'address' G_DBUS_DEBUG option that will print out useful
debug information such as
GDBus-debug:Address: In g_dbus_address_get_for_bus_sync() for bus type `session'
GDBus-debug:Address: env var DBUS_SESSION_BUS_ADDRESS is not set
GDBus-debug:Address: env var DBUS_SYSTEM_BUS_ADDRESS is not set
GDBus-debug:Address: env var DBUS_STARTER_BUS_TYPE is not set
GDBus-debug:Address: Running `dbus-launch --autolaunch=05e508961149264c9b750a4c494aa6f7 --binary-syntax --close-stderr' to get bus address (possibly autolaunching)
GDBus-debug:Address: dbus-launch output:
0000: 75 6e 69 78 3a 61 62 73 74 72 61 63 74 3d 2f 74 unix:abstract=/t
0010: 6d 70 2f 64 62 75 73 2d 77 42 41 6f 4b 59 49 52 mp/dbus-wBAoKYIR
0020: 7a 75 2c 67 75 69 64 3d 30 34 30 64 31 33 66 33 zu,guid=040d13f3
0030: 30 61 30 62 35 32 63 32 30 66 36 32 63 34 31 63 0a0b52c20f62c41c
0040: 30 30 30 30 35 30 38 64 00 d2 38 00 00 01 00 40 0000508d..8....@
0050: 05 00 00 00 00 .....
GDBus-debug:Address: dbus-launch stderr output:
14542: Autolaunch enabled (using X11).
14542: --exit-with-session automatically enabled
14542: Connected to X11 display ':0.0'
14542: === Parent dbus-launch continues
14542: Waiting for babysitter's intermediate parent
14542: Reading address from bus
14542: Reading PID from daemon
14542: Saving x11 address
14542: Created window 88080385
14542: session file: /root/.dbus/session-bus/05e508961149264c9b750a4c494aa6f7-0
14542: dbus-launch exiting
GDBus-debug:Address: Returning address `unix:abstract=/tmp/dbus-wBAoKYIRzu,guid=040d13f30a0b52c20f62c41c0000508d' for bus type `session'
and
GDBus-debug:Address: In g_dbus_address_get_for_bus_sync() for bus type `session'
GDBus-debug:Address: env var DBUS_SESSION_BUS_ADDRESS is not set
GDBus-debug:Address: env var DBUS_SYSTEM_BUS_ADDRESS is not set
GDBus-debug:Address: env var DBUS_STARTER_BUS_TYPE is not set
GDBus-debug:Address: Running `dbus-launch --autolaunch=05e508961149264c9b750a4c494aa6f7 --binary-syntax --close-stderr' to get bus address (possibly autolaunching)
GDBus-debug:Address: dbus-launch output:
0000: 75 6e 69 78 3a 61 62 73 74 72 61 63 74 3d 2f 74 unix:abstract=/t
0010: 6d 70 2f 64 62 75 73 2d 77 42 41 6f 4b 59 49 52 mp/dbus-wBAoKYIR
0020: 7a 75 2c 67 75 69 64 3d 30 34 30 64 31 33 66 33 zu,guid=040d13f3
0030: 30 61 30 62 35 32 63 32 30 66 36 32 63 34 31 63 0a0b52c20f62c41c
0040: 30 30 30 30 35 30 38 64 00 d2 38 00 00 01 00 40 0000508d..8....@
0050: 05 00 00 00 00 .....
GDBus-debug:Address: dbus-launch stderr output:
14549: Autolaunch enabled (using X11).
14549: --exit-with-session automatically enabled
14549: Connected to X11 display ':0.0'
14549: dbus-daemon is already running. Returning existing parameters.
14549: dbus-launch exiting
GDBus-debug:Address: Returning address `unix:abstract=/tmp/dbus-wBAoKYIRzu,guid=040d13f30a0b52c20f62c41c0000508d' for bus type `session'
Note that things work exactly like libdbus, e.g. from the
dbus-launch(1) man page:
Whenever an autolaunch occurs, the application that had to start a
new bus will be in its own little world; it can effectively end up
starting a whole new session if it tries to use a lot of bus
services. This can be suboptimal or even totally broken, depending
on the app and what it tries to do.
[...]
You can always avoid autolaunch by manually setting
DBUS_SESSION_BUS_ADDRESS. Autolaunch happens because the default
address if none is set is "autolaunch:", so if any other address is
set there will be no autolaunch. You can however include autolaunch
in an explicit session bus address as a fallback, for example
DBUS_SESSION_BUS_ADDRESS="something:,autolaunch:" - in that case if
the first address doesn't work, processes will autolaunch. (The bus
address variable contains a comma-separated list of addresses to
try.)
Signed-off-by: David Zeuthen <davidz@redhat.com>
Add a <flags> tag to the schema file format and a flags='' attribute to
go along with. Add some extra test cases for those.
Add new g_settings_{get,set}_flags() calls and support binding to
GParamSpecFlags properties. Add test cases.
This commit adds the following G_DBUS_DEBUG flags
- emission
- incoming
- call
- signal
- payload
https://bugzilla.gnome.org/show_bug.cgi?id=620913
Signed-off-by: David Zeuthen <davidz@redhat.com>
Without this guarantee, peer-to-peer connections are not very
useful. However, with this guarantee it's possible to export objects
in a handler for the GDBusServer::new-connection signal.
There are two caveats with this patch
- it won't work on message bus connections
- we don't queue up messages to be written
that can be addresses later if needed.
https://bugzilla.gnome.org/show_bug.cgi?id=623142
Signed-off-by: David Zeuthen <davidz@redhat.com>
Having this tool in GLib is a bad idea for a number of reasons:
- experience has shown that the simple file format was a bad idea
- the tool is currently implemented with a hack that would require a
dependency inversion to solve (the tool needs to depend on Python
GVariant bindings)
- the tool itself is unmaintained
It will be moved to the GConf git repository so people can continue to
use it for the purpose of converting GConf schemas.
GBinding is a simple, opaque object that represents a binding between a
property on a GObject instance (source) and property on another GObject
instance (target).
https://bugzilla.gnome.org/show_bug.cgi?id=348080
g_object_notify_by_pspec() will emit the "notify" signal on the given
pspec, short-circuiting the hash table lookup needed by
g_object_notify(). The suggested and documented way of using
g_object_notify_by_pspec() is similar to the way of emitting signals
with their ID.
Emission tests (with no handler attached to the notify signal) show a
10-15% speedup over using g_object_notify().
https://bugzilla.gnome.org/show_bug.cgi?id=615425
Allow constructing a GDBusProxy for well-known names as discussed here
http://mail.gnome.org/archives/gtk-devel-list/2009-October/msg00075.html
including test cases.
Make it possible to create a GDBusProxy for a GBusType instead of a
GDBusConnection. This requires G_BUS_TYPE_NONE so add that too.
Nuke g_bus_watch_proxy() since one can now more or less use GDBusProxy
for this.
Port gdbus-example-watch-proxy to this new API and include this
example in the GDBusProxy doc page.
Also nuke the GType parameter from the GDBusProxy constructors as
requested here: https://bugzilla.gnome.org/show_bug.cgi?id=621229
Also update the porting guide and other API docs for this change.
Also fix a bug in the signal dispatching code so each subscriber only
get notified once, not N times, for the same signal. Also add a test
case for this.
https://bugzilla.gnome.org/show_bug.cgi?id=621213
Signed-off-by: David Zeuthen <davidz@redhat.com>
accept more than one callback.
g_bus_own_name_with_closures
g_bus_own_name_on_connection_with_closures
g_bus_watch_name_with_closures
g_bus_watch_name_on_connection_with_closures
g_bus_watch_proxy_with_closures
g_bus_watch_proxy_on_connection_with_closures
https://bugzilla.gnome.org/show_bug.cgi?id=621092
This adds a GApplication object to GIO, which is the core of
an application support class, supporting
- uniqueness
- exporting actions (simple scripting)
- standard actions (quit, activate)
The implementation for Linux uses D-Bus, takes a name on the
session bus, and exports a org.gtk.Application interface.
Implementations for Win32 and OS X are still missing.
add GSimplePermission, a trivial const implementation of GPermission
can-request and can-release are always false for this implementation and
the value of 'allowed' is decided at construction.
This adds static markers for dtrace, which are also usable
by systemtap. Additionally it adds a tapset for systemtap
that makes it easier to use the static markers.
These are enabled by default.
This initial set of probes is rather limited:
* allocation and free using g_malloc & co
* allocation and free using g_slice
* gquark name tracking (useful for converting quarks to strings in probes)
Notes on naming:
Its traditional with dtrace to use probe names with dashes as
delimiter (slice-alloc). Since dashes are not usable in identifiers
the C code uses double underscores (slice__alloc) which is converted
to dashes in the UI. We follow this for the shared lowlevel probe
names.
Additionally dtrace supports putting a "provider" part in the probe
names which is essentially a namespacing thing. On systemtap this
field is currently ignored (but may be implemented in the future), but
this is not really a problem since in systemtap the probes are
specified by combining the solib file and the marker name, so there
can't really be name conflicts.
For the systemtap tapset highlevel probes we instead use names that
are systemtapish with single dashes as separators.
https://bugzilla.gnome.org/show_bug.cgi?id=606044
Fixup for commit 133f66538d which
duplicated the contents of most of the migration documentation by
splitting it out into separate files but keeping the original file
intact (with a rename).
This removes the duplicated content from the renamed file.
This uncovered a bug in name watching if the name wasn't activatable.
Also provoked the need for on_connection variants of g_bus_watch_name
(added g_bus_watch_proxy's variant as well).
This makes it possible to use the cached properties mechanism even if
constructing the proxy with the DO_NOT_LOAD_PROPERTIES flag.
This is useful for cases where you obtain the and track object
properties out-of-band. For example, in udisks, the plan is to have
something like this
Manager.GetObjects (out ao paths, out aa{sa{sv}} all_properties);
Manager.ObjectAdded (o path, a{sa{sv}} all_properties);
Manager.ObjectChanged (o path, a{sa{sv}} all_properties);
Manager.ObjectRemoved (o path, a{sa{sv}} all_properties);
E.g. the first GetObjects() call will return *all* data about *all*
exported objects. Further, this way a client will only need to listen
these three signals (three AddMatch) on the Manager object and it will
never need to do GetAll() etc (e.g. can use DO_NOT_LOAD_PROPERTIES).
(Of course this only works if the client is interested in all
objects... while this is true for udisks it is generally not true for
other D-Bus services).
Also use expected_interface to check for programming errors.
Lots of people been suggesting this. We still use MethodInvocation /
method_invocation for handling incoming method calls so use call()
instead of invoke_method() helps to separate the client and server
facilities. Which is a good thing(tm).
