Rename the project to "install" the GLib files, as we are planning to have
a grand solution file that would build the entire GTK+ stack with its deps,
to ease the process for people building the GTK+ stack from a stock
installation of Visual Studio.
We are including the autocleanup headers as public headers for all builds,
although they work only for GCC in reality, so "install" them.
Also clean up a bit as we are having "\\" in places, where we only need
"\".
Automatically add support for the new cleanup macros to the type
declaration macros.
This is an API break because now your parent class needs to support
cleanup if you want to use G_DECLARE_*_TYPE. These macros are only 1
day old, however, so that's probably not a big problem (and we are
already busy adding the macros all over GLib and Gtk+).
https://bugzilla.gnome.org/show_bug.cgi?id=743640
Add g_auto() and g_autoptr() as helpers for declaring variables with
automatic cleanup.
Add some macros to help types define cleanup functions for themselves.
Going forward it will be an expectation that people use this macro when
creating a new type, even if they do not intend to use the auto-cleanup
functionality for themselves.
These new macros only work on GCC and clang, which is why we resisted
adding them for so long. There exist many people who are only
interested in writing programs for these compilers, however, and a
similar API in libgsystem has proven to be extremely popular, so let's
expose this functionality to an even wider audience.
We ignore deprecation warnings when emitting the free functions, which
seems suspicious. The reason that we do this is not because we want to
call deprecated functions, but just the opposite: sometimes the free
function will be an _unref() function that is only AVAILABLE_IN newer
versions, and these warnings are also implemented as deprecation
warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=743640
Make sure that we only match the _get_type() function name by
restricting the regexp to matching [A-Za-z0-9_]. We were matching on .*
before which means that if we had two _get_type() functions appearing on
a single line then we would get everything in between them included (by
the default rule of '*' being greedy).
This affected G_DECLARE_*_TYPE which puts several uses of _get_type()
into a single line.
GListModel is an interface that represents a dynamic list of GObjects.
Also add GListStore, a simple implementation of GListModel that stores
all objects in memory, using a GSequence.
https://bugzilla.gnome.org/show_bug.cgi?id=729351
Add G_DECLARE_DERIVABLE_TYPE() and G_DECLARE_FINAL_TYPE() to allow
skipping almost all of the typical GObject boilerplate code.
These macros make some assumptions about GObject best practice that mean
that they may not be usable with older classes that have to preserve
API/ABI compatibility with a time before these practices existed.
https://bugzilla.gnome.org/show_bug.cgi?id=389585
This adds a public API where one can use to see whether the running version
of Windows where the code is run is at least the specified version, service
pack level, and the type (non-server, server, any) of the running Windows
OS.
This API is done as:
-GetVersion()/GetVersionEx() changed in the way they work since Windows 8.1
[1][2], so a newer mechanism to check the version of the running Windows
operating system is needed. MSDN also states that GetVersion() might be
further changed or removed after Windows 8.1. This provides a wrapper for
VerfyVersionInfo() as well in GLib for most cases, which was recommended
in place of g_win32_get_windows_version() for more detailed Windows
version checking.
-Provides an OS-level functionality check, for those that we don't need to
venture into GetProcAddress(), and also to determine system API behavior
changes due to differences in OS versions.
Also added a note for the g_win32_get_windows_version() API that since the
behavior of GetVersion() which it uses, is changed since Windows 8.1, users
of the API should be aware.
[1]:
http://msdn.microsoft.com/zh-tw/library/windows/desktop/ms724451%28v=vs.85%29.aspx
[2]:
http://msdn.microsoft.com/zh-tw/library/windows/desktop/ms724451%28v=vs.85%29.aspxhttps://bugzilla.gnome.org/show_bug.cgi?id=741895
Currently the only way to set a state hint on an action is through a
subclass; add a g_simple_action_set_state_hint() method so that this
becomes easier for clients that already use GSimpleAction.
https://bugzilla.gnome.org/show_bug.cgi?id=743521
When implementing blocking operations on top of
nonblocking sockets we should always first try to
perform the operation and then if needed handle
EAGAIN and wait with g_socket_wait_condition.
This is an optimization since we avoid calling
wait condition when it is not needed, but most
importantly this fixes hangs on win32 where some
events (in particular FD_WRITE) are only emitted
after the operation fails with EWOULDBLOCK.
https://bugzilla.gnome.org/show_bug.cgi?id=732439https://bugzilla.gnome.org/show_bug.cgi?id=741707
Add a unit test that checks g_socket_new_from_fd by creating
a gsocket, obtaining its fd, duplicating the fd and then creating
a gsocket from the new fd. This shows a hang on win32 since the
gsocket created from the fd never receives the FD_WRITE event
because we wait for the condition without first trying to write
and windows signals the condition only after a EWOULDBLOCK error.
https://bugzilla.gnome.org/show_bug.cgi?id=741707
Include an example main() function, and include a link to the gettext
manual’s section on integrating gettext with build systems.
That should work as a complete reference for how to add i18n support to
an application.
https://bugzilla.gnome.org/show_bug.cgi?id=742972
We were asking for properties on NM's dbus interface, but if NM is not
running then there won't be any. Check if the name has an owner before
doing anything to it.
https://bugzilla.gnome.org/show_bug.cgi?id=741653
AC_C_BIGENDIAN can return 'universal' as the result in the case that we
are trying to do a universal build on Mac OS. This has to be opted into
explicitly by using multiple -arch CFLAGS.
Previously, we detected this result and fell back to doing our own check
based on the endianness of the build machine, hardcoding that. This
means that universal builds might successfully build, but the binaries
would never actually run correctly on the 'opposite' arch.
This check was added because of a bug in the intial implementation of
this detection in autoconf, which was inappropriately identifying
non-macos compilers as 'universal'. That was hitting ppc64 systems.
See https://bugzilla.redhat.com/show_bug.cgi?id=449944 for more info.
Commit b0e687ef42e21b1eb7af18c4eaebcd41b0bd5632 in autoconf ("Limit
AC_C_BIGENDIAN univeral checks to Mac OS X") solved this issue in 2008,
so let's remove our workaround. For good measure, if we detect
"universal" in the result, error out.
https://bugzilla.gnome.org/show_bug.cgi?id=742548
Update config.h.win32.in and glibconfig.h.win32.in so that they will be
in-line with the ones that are produced with configure.ac, for use on
Windows builds.
Thanks to Philip Withnall for pointing out the changes needed to update
glibconfig.h.win32.in in bug 727829.
