GData*Streams incur significant overhead, and we do not need all of the
functionality that they provide, since we only ever read from/write to
memory when handling message blobs, so it is more performant to use a
simple structure.
https://bugzilla.gnome.org/show_bug.cgi?id=652650
... and g_content_type_get_generic_icon_name(). The new functions are
implemented for Win32 since commit dace477c, so we no longer need to
guard them with G_OS_UNIX.
Just like g_timeout_add() and friends, we want to hide the unintrospectable
g_unix_signal_add() from GI bindings and present g_unix_signal_add_full() as
GLib.unix_signal_add() to them.
Really, the memory output stream API is too warped around the model
where it's a fixed size buffer that you've already allocated. Even in
C, I find myself always wanting to use it to just accumulate data into
an arbitrary-sized buffer it allocates.
Unfortunately, it's also not usable from bindings because it's not
common to bind g_free() and g_realloc(), but if you just pass NULL, you
get the default of a fixed size, which is useless as per above.
I am going to use this from a gjs test case, and the GSubprocess test
cases also will use it.
https://bugzilla.gnome.org/show_bug.cgi?id=688931
Add a pair of new APIs: one to GFile to create a new file from a
commandline arg relative to a given cwd and one to
GApplicationCommandLine to create a GFile from an arg, relative to the
cwd of the invoking commandline.
https://bugzilla.gnome.org/show_bug.cgi?id=689037
The gobject tools (glib-genmarshal and gobject-query) were linking
against libgthread. Stop that.
Also, remove the gthread_INCLUDES internal automake substitution.
Add aliases for codesets supported by iconv and included in locales.
Ifdef-out tests in glib/tests/gdatetime.c which fail because on OSX only
ASCII numbers or symbols are returned for the format.
Even though nl_langinfo does weird things on Darwin in some cases, it
still acts correctly when LANG/LC_ALL is set to a supported
locale.codeset.
If we fail to start (and don't register() or call startup()) then also
don't call shutdown(). This happens in the case of failing to parse
commandline arguments, for example.
Using "int main (int argc, char** argv)" in this test causes GCC to
issue two warnings about unused variable if CFLAGS envvar has
-Wunused-parameter (or just -Wextra). Those warnings are not related
to the attribute checking but they can make the test fail anyway.
gnome-session needs to know the startup id that was given to
a started app; this was not available via GAppLaunchContext.
This commit adds a ::launched signal to get this information.
At the same time, turn the launch_failed vfunc into a signal
as well.
https://bugzilla.gnome.org/show_bug.cgi?id=688497
gnome-session still uses EggDesktopFile, since GDesktopAppInfo is
missing a handful of APIs that are needed to implement the
autostart spec. This patch adds the minimum that is required.
https://bugzilla.gnome.org/show_bug.cgi?id=688497
As the project file format for Visual Studio 2012 is only slightly
different from Visual Studio 2010 projects, we can provide support for
building GLib (and other projects) with Visual Studio 2012 with relatively
little effort. This might change when we eventually get GLib to work with
the Windows 8 (Modern UI/formerly Metro) APIs, but this will suffice for
the time being for people needing to build GLib with Visual Studio 2012.
Basically all that needs to be done at 'make dist' is:
-Copy the .sln/.props/README.txt/.vcxproj files and replace the VS2010
stuff with VS2012 stuff
-Copy the .vcxproj.filters as is
This reverts commit 85976cf91d and
properly removes the offending symbols from gio.symbols.
These two private symbols were found to be exported during Colin's
recent work cleaning up function visibility (among other things).
They were never exposed in any header file and I am 100% certain that
they have never been used by anybody. They were always private -- only
exposed on the library symbol list.
This change will cause ABI checking tools to complain that we have
removed functions, but the change is completely harmless for actual
applications.
https://bugzilla.gnome.org/show_bug.cgi?id=687441
This reverts commit 028d4a03f2.
I thought that we would be able to get away with this incompatible
change but it appears to impact far too much existing code. The only
thing we can do is revert.
https://bugzilla.gnome.org/show_bug.cgi?id=688596
