Re: Gtk::GLArea and related demo - ongoing issue

[Daniel Hams <daniel hams gmail com>]

On Mon, Jul 13, 2015 at 1:32 PM, Daniel Hams <daniel hams gmail com> wrote:
> I've created a first attempt at getting Gtk::GLArea working plus
> something in the gtkmm-demo.
>
> ......

So as part of the implementation of this additional widget, the
question of how to put in place the underlying Gtk::GLArea get_error()
and set_error() functionality has arisen.

Rather than clutter up bugzilla with a discussion on this I thought
maybe we could discuss direction.

I'd like to propose as a first step that we get an agreement on the
_interface_ for it - and let that be the driver for working out the
appropriate _mechanism_.

So the existing C interface looks like this:

void gtk_gl_area_set_error( GtkGLArea *area, const GError *error);
GError * gtk_gl_area_get_error( GtkGLArea *area);

Kjell proposed a couple of possibilities in bugzilla
(https://bugzilla.gnome.org/show_bug.cgi?id=752314) - they vary in the
way that get_error is done.

The set_error() seems straightforward and has appropriate members for
checking if set and clearing one if set:

void GLArea::set_error( const Glib::Error& error);
bool GLArea::has_error() const;
void GLArea::unset_error();

The proposals for getting the error are the point of discussion:

(1) Glib::Error * GLArea::get_error() const;
(2) void GLArea::throw_if_error() const;

I proposed a signature in the current patch as follows:

(3) void GLArea::get_error( Glib::Error& out_error) const;

Issues with these are as follows:

(1) Returns a dynamically unmanaged instance
(2) Throws the error when you may simply wish to obtain it
(3) Glib:Error has derived classes and instances should be of that
derived class - doing it this way isn't using the correct derived
class

So, given the issues with the above approaches perhaps we need a
signature that returns a dynamically allocated derived error instance
but that is managed by a smart pointer?

i.e.

Glib::RefPtr<Glib::Error> GLArea::get_error() const;

Of course this means the _mechanism_ behind this needs some deeper
changes to implement some kind of error factory - currently it seems
that errors register a "throw method" into Glib::Error - perhaps this
could be refactored to register an error factory method.

Thoughts?

Cheers,

Dan