Fix regression in Pango >= 1.44 Hypens shown at end of first line

Closes evince#1242 and totem#349

See merge request !3

which is enabled by default, but can be set off by a new attribute.

As a result, GdTwoLinesRenderer is now showing a hyphen in some cases
at end of first line, which is bad for filenames (like Totem or Evince
recent files view) because a filename may already include hyphens so
showing an extra hyphen which is not part of the filename is confusing.

This is a regression that Pango devs are not going to fix but instead
provided a new attribute to set this off.

So to fix this regression, let's restore previous behaviour when using
Pango >= 1.44

Fixes evince#1242
Fixes totem#349

Resolve "Remove warning about g_type_class_add_private being deprecated"

Closes #2

See merge request !1

This commit removes the usage of g_type_class_add_private function and
starts to use G_DEFINE_TYPE_WITH_PRIVATE or G_DEFINE_TYPE_WITH_CODE
(... G_ADD_PRIVATE ...) in order to define a class with private members.

g_type_class_add_private is being deprecated since glib 2.58.

We no longer have a priv pointer inside the struct, and
G_DECLARE_DERIVABLE_TYPE has removed the need for the instance and
class typedefs. Therefore, this is a good time to clean up the header
and move the typedef for GdTwoLinesRendererPrivate into the .c file.

https://bugzilla.gnome.org/show_bug.cgi?id=774709

https://bugzilla.gnome.org/show_bug.cgi?id=774709

The current GObject recommendation is to use the generated
get_instance_private function instead of a separate priv pointer in the
instance struct. The saves one pointer per class in the heirarchy
multiplied by the number of instances of the type, and the function is
fast enough because it only does pointer arithmetic.

https://bugzilla.gnome.org/show_bug.cgi?id=774709

This paves the way for improving our GObject use and reducing the
amount of boilerplate.

G_DEFINE_WITH_WITH_PRIVATE was introduced in GLib 2.38, which should be
old enough for all users.

https://bugzilla.gnome.org/show_bug.cgi?id=774709

The code is trying to draw the border around a rubberband selection,
that's represented by a Cairo path. It's not necessarily a simple
rectangle, and, therefore, cannot be replaced by gtk_render_frame.
Let's disable the deprecation instead.

https://bugzilla.gnome.org/show_bug.cgi?id=742910

Generated files go in $(builddir), not $(srcdir).

(That was a trick to avoid requiring gir & vapi generation at build
time. But since libgd already requires vapigen & g-i at configure
time, it shouldn't be a problem to require them too at build-time)

https://bugzilla.gnome.org/show_bug.cgi?id=690972

There's no need to initialize an unsigned integer private member
variable to zero, because the entire struct is zero-initialized by
GObject.

Fallout from 4b7f3139

main-box directly depends on main-icon-box, and indirectly on gtk-hacks
through main-icon-box. Therefore, only specifying with-main-box should
include both main-icon-box and gtk-hacks.

https://bugzilla.gnome.org/show_bug.cgi?id=774709

We no longer have a priv pointer inside the struct, and
G_DECLARE_DERIVABLE_TYPE has removed the need for the instance and
class typedefs. Therefore, this is a good time to clean up the header
and move the typedef for GdTwoLinesRendererPrivate into the .c file.

https://bugzilla.gnome.org/show_bug.cgi?id=774709

https://bugzilla.gnome.org/show_bug.cgi?id=774709

The current GObject recommendation is to use the generated
get_instance_private function instead of a separate priv pointer in the
instance struct. The saves one pointer per class in the heirarchy
multiplied by the number of instances of the type, and the function is
fast enough because it only does pointer arithmetic.

https://bugzilla.gnome.org/show_bug.cgi?id=774709

This paves the way for improving our GObject use and reducing the
amount of boilerplate.

G_DEFINE_WITH_WITH_PRIVATE was introduced in GLib 2.38, which should be
old enough for all users.

https://bugzilla.gnome.org/show_bug.cgi?id=774709

We no longer have a priv pointer inside the struct, and
G_DECLARE_DERIVABLE_TYPE has removed the need for the instance and
class typedefs. Therefore, this is a good time to clean up the header
and move the typedef for GdStyledTextRendererPrivate into the .c file.

https://bugzilla.gnome.org/show_bug.cgi?id=774709

https://bugzilla.gnome.org/show_bug.cgi?id=774709

The current GObject recommendation is to use the generated
get_instance_private function instead of a separate priv pointer in the
instance struct. The saves one pointer per class in the heirarchy
multiplied by the number of instances of the type, and the function is
fast enough because it only does pointer arithmetic.

https://bugzilla.gnome.org/show_bug.cgi?id=774709

This paves the way for improving our GObject use and reducing the
amount of boilerplate.

G_DEFINE_WITH_WITH_PRIVATE was introduced in GLib 2.38, which should be
old enough for all users.

https://bugzilla.gnome.org/show_bug.cgi?id=774709

We no longer have a priv pointer inside the struct, and
G_DECLARE_DERIVABLE_TYPE has removed the need for the instance and
class typedefs. Therefore, this is a good time to clean up the header
and move the typedef for GdMainIconViewPrivate into the .c file.

https://bugzilla.gnome.org/show_bug.cgi?id=774709

https://bugzilla.gnome.org/show_bug.cgi?id=774709

The g_clear_pointer macro in GLib gained a bit of type safety when
using GCC and GCC-compatible compilers. It checks if the function
pointer is meant to accept a pointer to the type that the first
argument refers to. Now, GCC doesn't like it if the function pointer is
cast to GDestroyNotify, and emits this warning:
  warning: function called through a non-compatible type

Since the macro, even the earlier version of it, was explicitly
designed to avoid the need to cast the arguments, these redundant casts
should be removed.

glib#1425

Both main-icon-box and main-view need gtk-hacks during build time. Make
these widgets depend on gtk-hacks by default.

https://bugzilla.gnome.org/show_bug.cgi?id=793295

This will make the subsequent commit easier to read.

https://bugzilla.gnome.org/show_bug.cgi?id=793295

Otherwise, currently, the text is oddly biased towards the upper edge
of the cell. This is very clearly noticeable when there's no sub-title,
but is also discernable, although to a lesser degree, when there is.

This also matches what GtkCellRendererText does.

Some changes by Debarshi Ray.

https://bugzilla.gnome.org/show_bug.cgi?id=792665

This also matches what GtkCellRendererText does.

https://bugzilla.gnome.org/show_bug.cgi?id=792665

The PangoLayouts are only needed for gd_two_lines_renderer_get_size,
which can prepare them itself.

https://bugzilla.gnome.org/show_bug.cgi?id=792665

The text rendered by the TwoLinesRenderer is vertically aligned to
touch its border with the TogglePixbufRenderer. This was only working
this way because TwoLinesRenderer was ignoring its y-offset and always
treating it as zero.

Ignoring the y-offset causes problems when the TwoLinesRenderer needs
to obey some other alignment, and will, therefore, be fixed in the
subsequent commits. To prevent those fixes from breaking the
MainIconView it is necessary to specify the desired vertical alignment.

https://bugzilla.gnome.org/show_bug.cgi?id=792665

Order gtk-hacks below widgets requiring it in the macro.

Apparently the order of conditional dependencies matter for m4 macros.
For example, main-view is depending on gtk-hacks, but gtk-hacks is
defined before main-view and did not get picked up. This resulted in
linking errors when gtk-hacks itself was omitted from the superprojects
init.

https://bugzilla.gnome.org/show_bug.cgi?id=780692

https://bugzilla.gnome.org/show_bug.cgi?id=786197

Libgd itself neither has a config.h, nor does it need one. Including
config.h risks conflicting with pre-processor macros that might be
defined by both libgd and the code that's using it. Eg., G_LOG_DOMAIN.

astian authored Jul 19, 2017 and Bastien Nocera committed Jul 20, 2017

https://bugzilla.gnome.org/show_bug.cgi?id=785159