-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
3.0 API: make parameters extensible #95
Comments
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 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 :-( |
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 |
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 :-) |
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
andviewrotation
were added, and be marked deprecated in favour of astroke(brush, surface, x, y, pressure, <EXTENSIONBLOB>)
method.The text was updated successfully, but these errors were encountered: