For static types, it should be possible to register a private data
structure right when we are registering the type, i.e. from the
get_type() implementation. By allowing this, we can take advantage of
the existing type definition macros to cut down the amount of code
necessary (as well as the knowledge baggage) when creating a new type.
The main issue with this new feature is that it cannot be mixed with the
old idiomatic way of adding private instance data by calling a function
in the middle of the class_init() implementation, as that imposes the
additional constraint of initializing the whole type hierarchy in order
to retrieve the offset of the private data in the GTypeInstance
allocation.
For this reason we are going to follow a two-step process; in the first
step, we are going to introduce the new (semi-private) API to register
the intent to add private instance data from within the get_type()
implementation, and hide it behind a macro; at the same time, the
G_DEFINE_TYPE_EXTENDED macro is going to be modified so that it will
register the private instance data if the macro was used, using a new
(semi-private) function as well. Once we have migrated all our code, we
will make the first new function perform the actual private data
registration, and turn the second new function into a no-op. This should
guarantee a transparent migration of existing code to the new idiomatic
form.
https://bugzilla.gnome.org/show_bug.cgi?id=700035
cd html && gtkdoc-mkhtml $mkhtml_options gio ../gio-docs.xml
../xml/gdbusconnection.xml:2063: parser error : Opening and ending tag mismatch: literal line 2062 and para
</para>
^
We do a bunch of new validity checks for return values in response to
calls on the D-Bus property API but we miss the 'goto out' in one case.
Add it.
https://bugzilla.gnome.org/show_bug.cgi?id=698375
Add some type checking for the values returned from async property
handling calls, similar in spirit to the type checking we do for normal
method calls.
https://bugzilla.gnome.org/show_bug.cgi?id=698375
The existing advice in the documentation to "simply" register the
"org.freedesktop.DBus.Properties" interface if you want to handle
properties asynchronously is pretty unreasonable. If you want to handle
this interface you have to deal with all properties for all interfaces
on the path, and you have to do all of the checking for yourself. You
also have to provide your own introspection data.
Introduce a new convention for dealing with properties asynchronously.
If the user provides NULL for their get_property() or set_property()
functions in the vtable and has properties registered then the
properties are sent to the method_call() handler. We get lucky here
that this function takes an "interface_name" parameter that we can set
to "org.freedesktop.DBus.Properties".
We also do the user the favour of setting the GDBusPropertyInfo on the
GDBusMethodInvocation for their convenience (for much the same reasons
as they might want the already-available GDBusMethodInfo).
Add a testcase as well as a bunch of documentation about this new
feature.
https://bugzilla.gnome.org/show_bug.cgi?id=698375
Separate the code for validating a method call from the code for
actually scheduling it for dispatch.
This will allow property Get/Set/GetAll calls to be dispatched to the
method_call handler without duplicating a lot of code.
https://bugzilla.gnome.org/show_bug.cgi?id=698375
We presently do a lot of checks on property sets (signature check,
correct interface, property exists, etc.) from the worker thread before
dispatching the call to the user's thread. The typecheck, however, is
saved until just before calling the user's vfunc, in their thread.
My best guess is that this was done to save having to unpack the value
from the tuple twice (since we don't unpack it until we're just about
the call the user).
This patch moves the check to the same place as all of the other checks.
The purpose of this change is to allow for sharing this check with the
(soon-to-be-introduced) case of handing property sets from
method_call().
This change has a minor side effect: error messages generated by sending
invalid values to property sets are no longer guaranteed to be correctly
ordered with respect to the void returns from successful property sets.
They will instead be correctly ordered with respect to the other error
messages.
https://bugzilla.gnome.org/show_bug.cgi?id=698375
0192c59937 moved this file from EXTRA_DIST TO
BUILT_EXTRA_DIST for an unknown reason.
Having it here causes the timestamp to be updated during 'make dist' to
something newer than docs/reference/*/Makefile.in. This is a problem
because those Makefile.in are generated by including gtk-doc.make, so
automake becomes convinced that they need to be regenerated. This is a
problem for people who don't have automake installed, or have the wrong
version.
The timestamp problem has been around for quite a while, but it only
became a problem recently after automake changed policy about this in
commit a22717dffe37f30ef2ad2c355b68c9b3b5e4b8c7.
Specifically:
https://bugzilla.gnome.org/show_bug.cgi?id=700350
We didn't actually do any real-world testing of this, and
unsurprisingly it turns out to break in at least one widely-used
configuration (Fedora 19 x86_64, ext4 on LVM).
This reverts commit 9d0c17b501.
https://bugzilla.gnome.org/show_bug.cgi?id=701560
Build and "install" the gio-querymodules and gdbus utility programs so that
the Visual Studio builds of GLib is more comprehensive. The Python scripts
for the GDBus codegen will be added to "installation" later.
The automatic memory management of GBinding is not optimal for high
order languages with garbage collectors semantics. If we leave the
binding instance inert but still referenced it will be leaked, so one
solution that does not throw away the baby of C convenience with the
bathwater of language bindability is to have unbind() perform an
implicit unref().
Hopefully, C developers will read the documentation and especially the
note that says that after calling unbind() the reference count on the
GBinding instance is decreased.
https://bugzilla.gnome.org/show_bug.cgi?id=698018
We have turned up enough cases of this being done (including GTK API
allowing apps to do this to GtkSettings well after it has been
instantiated) that it is clear that we cannot really break this feature
while claiming to be backwards compatible.
For that reason, it becomes a warning rather than a critical (ie: it is
still well-defined behaviour, but you are discouraged from doing it).
The intention is to keep this feature for at least the next while.
A given GObjectClass will be able to avoid using GParamSpec pool for as
long as you don't install properties after init. If you do that, you
will get a warning and we will devolve to using GParamSpecPool.
https://bugzilla.gnome.org/show_bug.cgi?id=698614
When parsing an address, we need to re-set "len" between IPv4 and
IPv6, since WSAStringToAddress() might set it to sizeof(struct sin_addr)
when trying to parse the string as IPv4, even if it fails. Also, we
need to make sure to not pass strings to WSAStringToAddress() that it
will accept but that we don't want it to.
When stringifying an address, we need to clear the sockaddr before
filling it in, so we don't accidentally end up with an unwanted
scope_id or the like.
https://bugzilla.gnome.org/show_bug.cgi?id=701401
Previously, g_file_copy() would (on Unix) create files with the
default mode of 644. For applications which might at user request
copy arbitrary private files such as ~/.ssh or /etc/shadow, a
world-readable copy would be temporarily exposed.
This patch is suboptimal in that it *only* fixes g_file_copy()
for the case where both source and destination are instances of
GLocalFile on Unix.
The reason for this is that the public GFile APIs for creating files
allow very limited control over the access permissions for the created
file; one can either say a file is "private" or not. Fixing
this by adding e.g. g_file_create_with_attributes() would make sense,
except this would entail 8 new API calls for all the variants of
_create(), _create_async(), _replace(), _replace_async(),
_create_readwrite(), _create_readwrite_async(), _replace_readwrite(),
_replace_readwrite_async(). That can be done as a separate patch
later.
https://bugzilla.gnome.org/show_bug.cgi?id=699959
Previously, we called g_file_query_info() *again* on the source at the
very end of the copy. This has the lame semantics that if the source
happened to be deleted, we would fail to apply attributes to the
destination. This could even be a security flaw.
This commit changes things so that we query info from the source
*stream* after opening - i.e. on Unix we use the proper fstat() and
friends. That way we operate more atomically.
https://bugzilla.gnome.org/show_bug.cgi?id=699959
The freedesktop application specification is largely overlapping the
GLib application D-Bus interface but implementing it will allow for
applications to be launched directly from desktop files, which we want.
We keep the old Gtk interface for compatibility reasons and because it
has some functionality not in the freedesktop spec (Busy state,
CommandLine, etc.).
https://bugzilla.gnome.org/show_bug.cgi?id=699259
Since services are based on D-Bus activation and desktop files are
supposed to be named like the busname for DBusActivatable applications
and since gnome-shell wants wmclass equal to the desktop file name, we
therefore want wmclass equal to the application ID in this case.
wmclass is determined from the prgname, which is otherwise pretty
pointless to set to some random thing in $(libexec) for a D-Bus service,
so set that to the appid.
This means that for D-Bus services, the following things are now all the
same:
- application ID
- prgname
- wmclass property set on all windows
- desktop file name
- well-known bus name
There are not many applications running as D-Bus services at present so
this shouldn't impact anybody except for gnome-clocks (where this change
will be fixing a bug) and gnome-terminal.
https://bugzilla.gnome.org/show_bug.cgi?id=699259
