3.0 API: make parameters extensible

[achadwick]

As mentioned in #92, methods that take lists of parameters that are only going to grow over time, such as mypaint_brush_stroke_to() should be implemented as variadic functions, or take as parameters an opaque extensible type (GHashTable or one of our own?). The goal is to prevent future pointless API+ABI breaks.

We have to take care to make it compatible with GObject-Introspection, even though that interface is languishing rather. I need to get my head around the almost nonexistent docs for it.

If it looks nicer, stroke_to() could go back to the old implementation before viewzoom and viewrotation were added, and be marked deprecated in favour of a stroke(brush, surface, x, y, pressure, <EXTENSIONBLOB>) method.

[briend]

So, is the idea to pass everything that is in brushsettings.json, so we can define new inputs including the min/max, etc on the fly? But what about calibration issues? Should we assume all inputs are calibrated as necessary before being passed to libmypaint, or should we come up with a way to describe the calibration that should be applied? Maybe New_Fabulous_Input needs to be calibrated against an internal libmypaint input like Direction, for instance. It would seem redundant to calculate Direction twice. What about naming the input, should there be a namespace that avoids collisions-- like GIMP.Fade? Fade is unique to GIMP, but Random is not, so GIMP might want to pass along GIMP.Random?

If it looks nicer, stroke_to() could go back to the old implementation before viewzoom and viewrotation were added, and be marked deprecated in favour of a stroke(brush, surface, x, y, pressure, ) method.

If those aren't provided, though, we'll have to default them to 1.0 and 0.0 respectively within libmypaint, I think, since they are calibrating several other inputs. In that respect they don't seem like extensions, more like a core input like x, y-- but I suppose it really doesn't matter one way or the other, right? Either way everyone has to change their applications :-(

[achadwick]

Not on the fly, no. And calibration for zoom, rotation, (virtual easel tilt, ambient temperature and humidity...) should happen in the brush engine now, right? 😉

I don't want to pan out anything too fancy on this one. Boring API technicalities only for now.

Going full GObject is an option for us. As is requiring GLib so that a GHashTable can be passed. Alternatively, a list of {special key and value type} with a count is eminently annotatable.

Whatever system we choose for the API should use the MYPAINT_BRUSH_INPUT_* consts as "keys" and doubles as the "values" of the input setting mapping. Let's not shoot for too much complexity at this point.

[briend]

Humidity. Haha. Don't give me ideas!

I think I understand now, the idea is just to not break existing stuff. New inputs won't magically work, but that's a problem for another day :-)