Remove dependency on Gtk.jl

[davidanthoff]

Fixes #15.

Or at least I think it does, I'm not entirely sure.

I'm not sure what the destroy function does/did. As far as I could tell it was actually not used, but I might misunderstand the design here.

In addition to the issue with the icon on Macs, I now also discovered that one can't use Rsvg.jl on juliabox because of the Gtk.jl dependency, so I think getting rid of that is even more beneficial than we originally thought.

It would be absolutely awesome if we could fix this quickly and tag a new release. I will give an official julia tutorial on Thu, and one of the packages I want to show off is https://github.com/fredo-dedup/VegaLite.jl, and I just now realized that it doesn't work on juliabox because of that Gtk.jl dependency. I would totally understand if we can't manage such a short turn around on such short notice, but I thought I might still ask :)

[davidanthoff]

Holy cow, and now I'm realizing that the seriously degraded REPL experience I've had for the last couple of months was actually caused by Gtk.jl as well (JuliaGraphics/Gtk.jl#325), and it was loaded because VegaLite.jl depends on Rsvg.jl, which loads Gtk.jl. So I think cutting that dependency really would be great, it seems just really not good that loading a package like Rsvg.jl then leads to a super crappy REPL...

[lobingera]

Well, "I'm not sure what the destroy function does/did. As far as I could tell it was actually not used, but I might misunderstand the design here." points rather to me not understanding the design, as with disconnecting the destroy from finalize memory management for Rsvg handles have been switched off (one still could call destroy manually).

I remember seeing julia complaints at closing REPL about pending allocations and i've seen other finalizer problems in Cairo, so in the long run we need to take a look.

What you do here is reducing the dependency on GError.

[davidanthoff]

I turned the finalizer on again, and I changed the destroy function to call rsvg_handle_free instead of whatever is going on in Gtk.jl. I think that is actually the correct way to handle that, if I understand the docs properly.

According to the librsvg docs, rsvg_handle_free is deprecated and one should instead call g_object_unref, but under the hood rsvg_handle_free just calls g_object_unref (see here), and this way we can just use the function that is exported in librsvg and be done.

If in the future there is a move to create a GLib.jl package, then one could instead update this to call g_object_unref directly, but maybe in the short term the solution in this PR here is good enough, right?