Now that RefPtr is really a std::shared_ptr<>, we should use
std::weak_ref<> instead.

Note that a std::weak_ptr<> tells you nothing about whether
the underlying GObject is still alive, which Glib::RefPtr did.
It just tells you whether our std::shared_ptr<> still holds
a reference to it. That's why I removed one of the checks in
tests/giomm_listmodel/main.cc.

Instead of Glib::RefPtr<>::cast_dynamic().

Specifying a Deleter in make_refptr_for_instance().
And changing RefPtr::cast_dynamic<>() to std::dynamic_pointer_cast<>().

The glibmm_refptr test then becomes rather silly, and should maybe
just be removed.

By adding a private IOSource constructor (and create()), accessible
via a friend declaration, that takes the raw GIOChannel.

See https://bugzilla.gnome.org/show_bug.cgi?id=755037#c20

By adding a private SocketSource constructor (and create()), accessible
via a friend declaration, that takes the raw GSocket.

See https://bugzilla.gnome.org/show_bug.cgi?id=755037#c20

This is necessary for C++17 which completely removes dynamic
exception specifications.
See https://bugzilla.redhat.com/show_bug.cgi?id=1438766

Instead of (deprecated) g_object_newv() and (deprecated) GParameter.

This seems to work. It is meant to be the simplest possible change.
I would like to translate this code properly to C++ now that I've noticed it.

This is necessary for C++17 which completely removes dynamic
exception specifications.
See https://bugzilla.redhat.com/show_bug.cgi?id=1438766

I forgot to update this before tagging the release.

The GOptionGroup contains a pointer to the Glib::OptionGroup wrapper.
That pointer can't be changed. Copying (adding a ref) or moving a
GOptionGroup to a second Glib::OptionGroup would be problematic.

So we can use the 2.51/52 version numbers for more stable releases.
We don't need to release a stable ABI-parallel glibmm until
we need to release gtkmm 4.0, and that won't happen until GTK+ 4.0.0
happens, and we don't know when that might be.

Each header file shall include all header files that it depends on.
Checked with tools/test_scripts/testheaders.sh

Glibmm requires c++14 now, and that's the default c++ version in the
latest gcc versions.

Some sources and headers have been removed lately...

Should have been done by commit 8c37e116,
I assume.

Remove the OptionGroup& parameter in on_pre_parse(), on_post_parse() and
on_error(). It's unnecessary. It's always identical to *this.
Add a const Error& parameter to on_error(). It's an input parameter with
information about an error that has occurred in OptionContext::parse().

GOptionGroup is refcounted. Glib::OptionGroup::has_ownership is unnecessary.
Replace gobj_give_ownership() by gobj_copy().
Glib::OptionGroup is not made refcounted, for reasons explained in a
comment in optiongroup.hg.

We don't use them in glibmm and gtkmm and I have never heard of anybody
ever using them.

Using Glib::ListHandler<>::list_to_array() and
Glib::ListHandler<>::list_to_vector() instead, and only in the
implementation instead of in the API.

Using Glib::ListHandler<>::list_to_array() and
Glib::ListHandler<>::list_to_vector() instead, and only in the
implementation instead of in the API.

* glib/glibmm.h: Remove streamiochannel.h.
* glib/glibmm/filelist.am: Remove streamiochannel.[cc|h].
* glib/glibmm/streamiochannel.[cc|h]: Removed files.
* glib/src/iochannel.[ccg|hg]: Remove the default constructor and the
deprecated virtual functions. In .ccg, remove the local GlibmmIOChannel
class. It's useless without the virtual functions, as is the default ctor.

Using Glib::ArrayHandler<>::vector_to_array() and
Glib::ArrayHandler<>::array_to_vector() instead, and only in the
implementatoin instead of in the API.

Using Glib::ArrayHandler<>::vector_to_array() and
Glib::ArrayHandler<>::array_to_vector() instead, and only in the
implementatoin instead of in the API.

Using Glib::ArrayHandler<>::vector_to_array() and
Glib::ArrayHandler<>::array_to_vector() instead, and only in the
implementatoin instead of in the API.

Using Glib::ArrayHandler<>::vector_to_array() and
Glib::ArrayHandler<>::array_to_vector() instead, and only in the
implementatoin instead of in the API.

Using Glib::ArrayHandler<>::vector_to_array() and
Glib::ArrayHandler<>::array_to_vector() instead, and only in the
implementatoin instead of in the API.

Using Glib::ArrayHandler<>::vector_to_array() and
Glib::ArrayHandler<>::array_to_vector() instead, and only in the
implementatoin instead of in the API.

There was a non-generated source that needs to be built as well, which
was missed in the update to the projects.  Also fix a typo in the
"install" project

Krzysztof Piecuch authored Mar 15, 2017 and Murray Cumming committed Mar 15, 2017

make_valid replaces all non-UTF8 characters with replacement
character (U+FFFD). Allows manipulating with ustring after you find
out by ustring::validate() that it's not an UTF-8 string and you
need to rescue it somehow.

This wraps g_utf8_make_valid().

Bug #780075

Let people know that libsigc++-3.x is required, and for Visual Studio
builds, Visual Studio 2017 is required.

Visual Studio 2017 is required to support the C++-14 features that
glibmm-2.52 will require, so update the projects to 2017.  Make the
projects look for libsigc++-3.x as well.

Also make sure that the glibmm and giomm projects are up-to-date, and
drop the threading examples projects as these examples have been dropped
from the tree, and ensure the headers "installed" are up-to-date.

Bug 779936