Commit Graph

1182 Commits

Author SHA1 Message Date
Dan Winship
8e17040c15 Fix overloading of "source" and "target" terminology in GBinding
GBindingTransformFunc called its arguments "source_value" and
"target_value", but in the transform_from function of a bidirectional
binding, "source_value" comes from the target object, and
"target_value" comes from the source object, which quickly gets
confusing if you need to use g_binding_get_source(), etc, in the
function.

Of course developers can call their transform function arguments
whatever they want, but many will copy from the headers/docs to start
out, so use less confusing names here ("from_value" and "to_value").

Also, fix the documentation to describe the bidirectional case
correctly.

https://bugzilla.gnome.org/show_bug.cgi?id=709440
2013-10-06 14:24:43 -04:00
Simon Feltman
2f57139b28 Fix crashes in various GParamSpec creation functions
Add NULL check and return after calls to g_param_spec_internal in GParamSpec
creation functions. This avoids glib crashing due to things like badly named
properties.

https://bugzilla.gnome.org/show_bug.cgi?id=707887
2013-10-01 18:31:17 -07:00
Misty De Meo
54e79d7dcb gobject: Fix compilation on OS X/ppc64
Apple's GCC compilers cannot deal well with 64-bit pointers in
transparent unions on ppc64, so compilation of
_G_DEFINE_BOXED_TYPE_BEGIN was failing. Fortunately glib already
provides a fallback for compilers that can't deal with it; this adds
this specific case to the check.

https://bugzilla.gnome.org/show_bug.cgi?id=647145
2013-09-19 08:39:18 -04:00
Martin Pitt
ed1e3816ad gobject-2.0: Annotate another GSignal function taking instances
As a followup to commit a72983a, annotate g_signal_handlers_destroy() as well.
2013-09-02 12:04:43 +02:00
Emmanuele Bassi
a72983a5db gobject-2.0: Annotate GSignal functions taking instances
Unbreak the GSignal API at least for GObject sub-classes.

https://bugzilla.gnome.org/show_bug.cgi?id=685387
2013-09-02 08:25:56 +02:00
Dan Winship
34e1a53795 gtype: fix a no-op assertion
g_type_class_add_private() was doing

    g_assert (node->data->instance.private_size <= 0xffff);

but that field is a guint16, so the check was a no-op. (Noticed by
clang, but not gcc for some reason.) Fix it to do the math in a gssize
variable and do the bounds checking there before updating the struct
field.

https://bugzilla.gnome.org/show_bug.cgi?id=706888
2013-08-27 09:42:14 -04:00
Dieter Verfaillie
9bcb6d3f00 Fix G_DEFINE_ABSTRACT_TYPE_WITH_PRIVATE documentation
https://bugzilla.gnome.org/show_bug.cgi?id=706469
2013-08-22 20:52:17 +02:00
Matthias Clasen
0e9f9867fa Start using TAP
Convert {glib,gobject,gio}/tests to use the automake TAP driver
and test harness instead of gtester. To do so, we add a glib-tap.mk
that provides the same interface as glib.mk, except for the
reporting and coverage testing functionality. Eventually, we may
want to replace glib.mk with it. I've not yet converted the
toplevel tests/ directory, since it mixes gtestutils tests with
other binaries.

https://bugzilla.gnome.org/show_bug.cgi?id=692125
2013-08-17 17:25:58 -04:00
Dan Winship
f550c0dc9d update .gitignores 2013-08-17 10:35:13 -04:00
Dan Winship
fd5b1939bd build: fix dtrace-related warnings
Fix the warnings when compiling and linking the probes files by
calling dtrace with all the -W flags removed from CFLAGS (since dtrace
generates bad C code), and with CC set to "libtool --mode=compile ..."
(so that it will output a proper .lo file and libtool won't warn when
linking it into the .la).

https://bugzilla.gnome.org/show_bug.cgi?id=693335
2013-08-17 10:34:32 -04:00
Nick Schermer
4b334ef8f1 gobject: Handle ref_count==0 in notify_by_pspec
Just like g_object_notify, check for a zero ref_count in
g_object_notify_by_pspec and leave if it is 0.

This allows using functions in ->finalize() that possibly also
notify a property change on the object.  Previously,
this resulted in an error from g_object_ref.

https://bugzilla.gnome.org/show_bug.cgi?id=705570
2013-08-14 18:11:05 +01:00
Emanuele Aina
66233f1d1b gtype: Fix typo in g_type_class_add_private() error message
https://bugzilla.gnome.org/show_bug.cgi?id=705398
2013-08-04 08:15:30 +02:00
Sébastien Wilmet
9551a81198 Fix G_ADD_PRIVATE_DYNAMIC() 2013-07-29 17:29:05 +02:00
Matthias Clasen
90da4ed628 Trivial typo fix 2013-07-28 22:06:57 -04:00
Rico Tzschichholz
023e3b31a5 Fix a typo
Introduced by 3b01cbe8a8
2013-07-27 09:02:58 +02:00
Emmanuele Bassi
ca6b93d093 Add macros and symbols for private data on dynamic types
We need a TypeName_private_offset variable defined by the macros used to
register dynamic types. We also need to call the adjust_private_offset()
function inside class_init(). G_ADD_PRIVATE_DYNAMIC only sets the size
of the private data structure, and relies on the behaviour of the
g_type_class_adjuset_private_offset() function to register the private
data structure at class init time if passed a value greater than zero.

This allows using G_PRIVATE_OFFSET with dynamic types.
2013-07-26 20:56:54 -04:00
Matthias Clasen
3b01cbe8a8 Document restrictions on private names
With the new machinery, private structs must be named
TypeNamePrivate if TypeName is the name of the instance
struct.
2013-07-26 14:42:22 -04:00
Colin Walters
d9e01e0c37 tests/closure: Send SIGUSR1 only to our pid
Otherwise in e.g. the gnome-ostree integrationtest system, we
end up sending SIGUSR1 to the *entire session*, which triggers
various badness in untested debugging paths from gnome-session.
2013-07-22 15:14:34 +01:00
Colin Walters
00f5c63621 tests/closure: Use correct prototype for signal callback
This test worked when compiled without optimization, but fails with
-O2.  Presumably we just happened to find the GMainLoop off the stack
somewhere.

https://bugzilla.gnome.org/show_bug.cgi?id=704267
2013-07-22 09:34:24 -04:00
Chun-wei Fan
114b1ccf78 gsourceclosure.c: Fix build on Windows
GPid is a HANDLE (aka void *) on Windows, not an int, so treat pid
accordingly on Windows, as using pid as a gulong directly would likely be
undesirable on Windows

https://bugzilla.gnome.org/show_bug.cgi?id=704447
2013-07-21 20:50:34 +01:00
Dan Winship
88ab63155d gobject/tests/closure: fix on win32
(The g_closure_unref() was wrong, but was not causing errors on linux
for some reason.)

https://bugzilla.gnome.org/show_bug.cgi?id=704447
2013-07-21 20:50:11 +01:00
Colin Walters
35e331b869 tests/closure: Fix invalid unref
The closure is floating, g_source_set_closure() will claim the
ref, so we do not need to unref it.
2013-07-21 19:42:34 +01:00
Sébastien Wilmet
b3968fb150 Improve documentation
- Mention G_SOURCE_CONTINUE and G_SOURCE_REMOVE in the GSourceFunc doc;
- Mention G_PARAM_READWRITE and G_PARAM_STATIC_STRINGS in the
  GParamFlags doc;
- Fix "Since:" version for G_DEFINE_ABSTRACT_TYPE_WITH_PRIVATE;
- Fix typo.

https://bugzilla.gnome.org/show_bug.cgi?id=704250
2013-07-20 11:07:46 +02:00
Dan Winship
72a7e824d6 gsourceclosure: fix idle/timeout/signal closures, add child watch support
And add a test for all source types.

https://bugzilla.gnome.org/show_bug.cgi?id=704267
2013-07-17 21:41:45 -04:00
Dan Winship
8a89926532 gsourceclosure: Add support for GUnixSignalWatchSource and GUnixFDSource
https://bugzilla.gnome.org/show_bug.cgi?id=701511
2013-07-13 16:38:55 -04:00
Dan Winship
1da47d5ede gsourceclosure: use g_cclosure_marshal_generic
For the glib-defined source types, and any source type that defines a
closure callback but not a closure marshal, use
g_cclosure_marshal_generic. And then remove all the other remaining
source closure marshals.

https://bugzilla.gnome.org/show_bug.cgi?id=701511
2013-07-13 16:38:55 -04:00
Emmanuele Bassi
a4c352cd99 Ensure that MAX_ALLOWED keeps working with the type macros
When using the GLIB_VERSION_MAX_ALLOWED macro to define the upper bound
of allowed API the G_DEFINE_TYPE_EXTENDED starts warning about the newly
added g_type_class_adjust_private_offset() function; this effectively
introduces a run-time dependency on GLib 2.38 even if we don't use its
API explicitly.

https://bugzilla.gnome.org/show_bug.cgi?id=703191
2013-07-03 09:37:03 -04:00
Emmanuele Bassi
54cc43630d Rename the generated private data getter function
As it turns out, we have examples of internal functions called
type_name_get_private() in the wild (especially among older libraries),
so we need to use a name for the per-instance private data getter
function that hopefully won't conflict with anything.
2013-06-24 15:43:04 +01:00
Emmanuele Bassi
aba80eea6c gparam: Use the new private instance data API
https://bugzilla.gnome.org/show_bug.cgi?id=700035
2013-06-24 14:18:01 +01:00
Emmanuele Bassi
39ba7c8142 gobject: Add private field access macros
Similar to G_STRUCT_MEMBER and G_STRUCT_MEMBER_P, but automatically using
the G_PRIVATE_OFFSET macro.

https://bugzilla.gnome.org/show_bug.cgi?id=700035
2013-06-24 14:18:01 +01:00
Emmanuele Bassi
d91d114a54 Add G_PRIVATE_OFFSET
A macro that evaluates to the offset of a field inside an instance
private data structure.

https://bugzilla.gnome.org/show_bug.cgi?id=700035
2013-06-24 14:18:01 +01:00
Emmanuele Bassi
d3dec6ec80 Allow registering instance private data during get_type()
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
2013-06-24 14:18:01 +01:00
Colin Walters
18702168e1 gobject/tests: Add missing build dependency 2013-06-17 13:05:11 -04:00
Emmanuele Bassi
910732ea7e tests/binding: Ensure that the binding goes away
Use weak pointers so that we can check that the GBinding instance goes
away when it should.

https://bugzilla.gnome.org/show_bug.cgi?id=698018
2013-06-12 11:24:55 +01:00
Emmanuele Bassi
d1959e4faa binding: Use hash table as a set 2013-06-12 11:24:55 +01:00
Emmanuele Bassi
25a3c8720c binding: Make unbind() release the reference on GBinding
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
2013-06-12 11:24:55 +01:00
Ryan Lortie
c1e32a5c59 GObject: turn add-property-after-init to a warning
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
2013-06-10 11:18:06 -04:00
Ryan Lortie
f9eb9eed10 Rework the build system for a new tests approach
Perform a substantial cleanup of the build system with respect to
building and installing testcases.

First, Makefile.decl has been renamed glib.mk and substantially
expanded.  We intend to add more stuff here in the future, like canned
rules for mkenums, marshallers, resources, etc.

By default, tests are no longer compiled as part of 'make'.  They will
be built when 'make check' is run.  The old behaviour can be obtained
with --enable-always-build-tests.

--disable-modular-tests is gone (because tests are no longer built by
default).  There is no longer any way to cause 'make check' to be a
no-op, but that's not very useful anyway.

A new glibtests.m4 file is introduced.  Along with glib.mk, this
provides for consistent handling of --enable-installed-tests and
--enable-always-build-tests (mentioned above).

Port our various test-installing Makefiles to the new framework.

This patch substantially improves the situation in the toplevel tests/
directory.  Things are now somewhat under control there.  There were
some tests being built that weren't even being run and we run those now.
The long-running GObject performance tests in this directory have been
removed from 'make check' because they take too long.

As an experiment, 'make check' now runs the testcases on win32 builds,
by default.  We can't run them under gtester (since it uses a pipe to
communicate with the subprocess) so just toss them in TESTS.  Most of
them are passing on win32.

Things are not quite done here, but this patch is already a substantial
improvement.  More to come.
2013-05-31 23:12:15 -04:00
Ryan Lortie
a8a9afe17c GObject: prevent installing properties after init
GObject has previously allowed installing properties after class_init
has finished running.  This means that you could install some of your
own properties on G_TYPE_OBJECT, for example, although they wouldn't
have worked properly.

A previous patch asserted that this was not true and we had to revert it
because it broke the shell.  Instead of reverting, we should have used a
critical, so do that now.

Complaints go to this bug:

https://bugzilla.gnome.org/show_bug.cgi?id=698614
2013-05-29 09:25:25 -04:00
Ryan Lortie
da478acd3c Remove G_TEST_DATA= from installed .test files
This is no longer needed with the new test data file finding stuff.

https://bugzilla.gnome.org/show_bug.cgi?id=549783
2013-05-29 09:03:32 -04:00
Matthias Clasen
2afd39a90d Trivial doc typo fix 2013-05-29 08:38:03 -04:00
Matthias Clasen
2349635ebe Trivial documentation typos 2013-05-29 08:37:57 -04:00
Matthias Clasen
07168724d7 Improve signal test coverage 2013-05-29 08:37:19 -04:00
Matthias Clasen
a9abbb3192 Improve test coverage in gobject/
Lines:          6631    8862    74.8 %
Functions:      747     893     83.7 %
2013-05-29 08:37:08 -04:00
Colin Walters
0b167b0ae9 build: Fix usage of %.test again
We actually need the first dependency because it includes the
final executable name.  Rather, fix the original bug by using
the variable $(EXEEXT).
2013-05-24 22:16:44 +01:00
Colin Walters
5088c705ac tests: Drop unnecessary % from .test pattern match rule
On Windows, the executables will have .exe, so this won't
match.  Furthermore, they aren't actually dependent on the
executable to build.
2013-05-24 16:30:21 -04:00
Ryan Lortie
3d1d49177b gsignal: remove some pointless locking
We previously hold a lock in the loop that collects the arguments for
g_signal_emit(), which we drop before calling into the argument
collection functions and reacquire again at the bottom of the loop (ie:
one release/acquire pair for each argument collected).  To make matters
worse, the lock is just released again after the loop.

Presumably that was done to protect the access to the parameter array,
but it's pretty unlikely that this is needed because the only way it
changes is if the signal is unloaded.  That only happens when unloading
types which is quite unlikely to happen while we are emitting on an
instance of that type (and, as an aside, never happens anymore anyway).

If we move the unlock below the loop up above it and remove the
acquire/release pair from the loop, we improve performance in the new
arg-collecting performance tests by ~15% (more like ~18% in the case
where we only emit to one handler -- where argument collection dominates
more).

https://bugzilla.gnome.org/show_bug.cgi?id=694380
2013-05-23 21:50:54 -04:00
Dan Winship
4b94c0831e Use 'dumb quotes' rather than `really dumb quotes'
Back in the far-off twentieth century, it was normal on unix
workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
APOSTROPHE to be drawn as "’". This led to the convention of using
them as poor-man's ‛smart quotes’ in ASCII-only text.

However, "'" is now universally drawn as a vertical line, and "`" at a
45-degree angle, making them an `odd couple' when used together.

Unfortunately, there are lots of very old strings in glib, and also
lots of new strings in which people have kept up the old tradition,
perhaps entirely unaware that it used to not look stupid.

Fix this by just using 'dumb quotes' everywhere.

https://bugzilla.gnome.org/show_bug.cgi?id=700746
2013-05-21 11:23:22 -03:00
Matthias Clasen
f66016261a Make gobject tests installable
This makes the gobject tests run as part of the ostree integration
tests.
2013-05-19 21:49:51 -04:00
Dan Winship
e3d1869ee3 tests: port from g_test_trap_subprocess() to g_test_trap_fork()
https://bugzilla.gnome.org/show_bug.cgi?id=679683
2013-05-13 12:10:52 -04:00