glib/gobject/tests/.gitignore

binding
boxed
dynamictests
enums
ifaceproperties
param
properties
qdata
reference
signals
threadtests
valuearray
private
marshalers.[ch]
property
gobject: Add GBinding 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 2010-06-04 16:17:15 +01:00			`binding`
Improve .gitignore 2011-03-31 15:51:01 +05:30			`boxed`
update .gitignores 2009-12-18 12:27:36 +01:00			`dynamictests`
Improve .gitignore 2011-03-31 15:51:01 +05:30			`enums`
			`ifaceproperties`
			`param`
gobject: Add install_properties() Since we added g_object_notify_by_pspec(), an efficient way to install and notify properties relies on storing the GParamSpec pointers inside a static arrays, like we do for signal identifiers. Instead of multiple calls to g_object_class_install_property(), we should have a single function to take the static array of GParamSpecs and iterate it. https://bugzilla.gnome.org/show_bug.cgi?id=626919 Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com> 2010-08-18 15:32:27 +01:00			`properties`
update .gitignore 2012-09-03 08:56:10 -04:00			`qdata`
New function: g_clear_object() By analogy to g_clear_error, takes a pass-by-reference GObject reference and, if non-%NULL, unrefs it and sets it equal to %NULL. Bug #620263. 2010-11-08 16:42:32 -05:00			`reference`
Improve .gitignore 2011-03-31 15:51:01 +05:30			`signals`
Bug 549771 – improved .gitignore for glib 2007-09-02 Ryan Lortie <desrt@desrt.ca> Bug 549771 – improved .gitignore for glib * docs/reference/.gitignore: * docs/reference/gio/.gitignore: * docs/reference/gobject/tmpl/.gitignore: * gio/.gitignore: * gio/tests/.gitignore: * glib/.gitignore: * glib/libcharset/.gitignore: * glib/tests/.gitignore: * gmodule/.gitignore: * gobject/.gitignore: * gobject/tests/.gitignore: * po/.gitignore: * tests/.gitignore: new files * .gitignore: remove 'build' (since it's part of glib now), add more useful things. svn path=/trunk/; revision=7432 2008-09-02 18:40:39 +00:00			`threadtests`
gitignore tweaks 2011-07-22 15:47:11 +02:00			`valuearray`
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-05-09 14:41:26 -07:00			`private`
build: Fix rules for marshalers.[ch] 2012-03-02 17:06:36 +00:00			`marshalers.[ch]`
gobject: Add GProperty Dealing with GParamSpec is tedious and less efficient than necessary. GParamSpec is a data type meant to be used to validate GValue, and only incidentally provides us with the facilities to implement properties on GObject. GObject itself requires us to provide accessors functions and then call them from within a huge switch() inside two virtual functions. Property definitions should be able to either directly access a struct field or specify the accessors pair that control a property. On top of that, most of the property and accessor definition can be autogenerated from simple pre-processor directives. So, here's to you GProperty. GProperty is a GParamSpec sub-class that encapsulates all the C fundamental types inside a single, opaque structure (to avoid leaking out implementation details); a GProperty can access the structure member holding the value of the property, or invoke the accessor functions passed to its constructor. Type safety is enforced at compile time through the C type system, and at run time through the GType system. GProperty will try very hard to avoid boxing and unboxing fundamental type values into GValues. GObject will recognize whether a GParamSpec used to set or get a property is really a GProperty, and thus will shortcircuit most of the GValue-based marshalled code, preferring the direct C function and direct argument collection instead of boxing/unboxing of GValues. https://bugzilla.gnome.org/show_bug.cgi?id=648526 2013-04-23 14:37:03 -04:00			`property`