These days people can just use GtkRevealer.

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 GdMainViewPrivate into the .c file.

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

This bumps our GLib requirement to 2.44.

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

gcc seems to be stripping away the "unused"
gd_tagged_entry_get_resource() when linking it. Call the function to
avoid the function being stripped away.

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

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

Otherwise automake will skip it as it is not included anywhere.

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

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

We have a .gitignore committed into version control, so we shouldn't be
overwriting it. This defeats the purpose of using git.mk as we wind up
with a dirty subproject after every build due to make rewriting our
tracked .gitignore. And libgd itself does not use git.mk, so it
shouldn't be here.

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

6eefe0ed added the .gresource.xml to the
distribution, but the CSS file it's supposed to include isn't
distributed. Also remove the generated resource headers from the
distribution.

Instead of having to copy/paste this custom style in every application,
install a default style provider.

Bastien Nocera authored Dec 01, 2015 and Cosimo Cecchi committed Dec 02, 2015

The tagged entry was generating loads of errors following CSS changes
in GTK+ 3.19.

See https://blogs.gnome.org/mclasen/2015/11/20/a-gtk-update/ for details
and work-arounds.

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

The line renderer was generating loads of errors following CSS changes
in GTK+ 3.19.

See https://blogs.gnome.org/mclasen/2015/11/20/a-gtk-update/ for details
and work-arounds.

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

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

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

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

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

Fall out from 1e049c22

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

This could cause nasty side effects messing up the whole rendering of
the GdTaggedEntry.

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

Reuse the entry's style context via save()/restore() instead of creating
a new style context all the time.

Solves a bunch of styling problems, such as value inheritance.

Since 3.15.12, GtkCellRendererPixbuf always follows state and the
follow-state property has been deprecated.

This reverts ac4ae160

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

It's a variant of gd_embed_image_in_frame() that takes a cairo_surface_t
instead of a GdkPixbuf.
gd_embed_image_in_frame() now is implemented on top of the surface
variant.

Note: while it may seem that this makes framing a pixbuf slower by
adding a pixbuf->surface conversion, GTK+ already implements
gtk_render_icon() on top of gtk_render_icon_surface() so it ends up
being the same.

Adrien Plazas authored Jun 19, 2015 and Zeeshan Ali committed Jun 19, 2015

This applies the model before applying the selection mode while
rebuilding. This is necessary because otherwise the model of the generic
view may not be set while applying the selection mode, causing critical
errors on console.

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

Currently we create an image that is larger than the one that is passed
to us. This can cause problems when the caller has already determined
the desired size of the icon.
Instead, clip the image inside the border.

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

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

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

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

Now all DnD icons are dealt with as cairo_surface_t, if pixbufs are used
in the data model, a cairo surface is created out of it first.

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

With recent versions of Adwaita/GTK+.

Apply all the necessary changes by hand, rather than relying on a
GtkStyleContext being able to transfer its style to a PangoLayout.

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

Matthias Clasen authored Sep 02, 2014 and Bastien Nocera committed Sep 03, 2014

GTK+ changed from using the active state to a new checked
state for this. Adapt the toggle cell renderer.

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

Matthias Clasen authored Sep 02, 2014 and Bastien Nocera committed Sep 03, 2014

Adwaita provides styling only for .app-notification.frame, so
add the .frame style class as well. And don't draw a shadow.

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

Draw background and border for the check box so that it can be styled
with css.

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

So that prelight works.

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

libgd's Makefile.am refers to source files in subdirectories, which
causes warnings with automake 1.14. Enabling the 'subdir-objects'
option silences these.

libgd/Makefile.am:29: warning: source file 'libgd/gd-types-catalog.c' is in a subdirectory,
libgd/Makefile.am:29: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled.  For now, the corresponding output
automake: object file(s) will be placed in the top-level directory.  However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.

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

Fallout from 41820ae9