@almarklein is there a compelling reason to use `*args, **kwargs` here instead of the actual arguments? I think it makes the function harder to use.

For example, I had tried instantiating the object with `Canvas('title', app)`, but this failed, since I needed to actually pass them as `kwargs` (which is unintuitive because almost all methods I've used you can pass in things as args or kwargs without penalty). This would not be an issue if the arguments were explicitly unpacked. I understand it's convenient to just pass `*args, **kwargs` to the `self._set_backend` method later, but to me this obscures the arguments, and makes it less usable to the end user.

It also makes the code harder to track / maintain. As a case in point, there is an argument `native` that gets `.pop`'ed later from `kwargs` that is not in the list of `kwargs`. I assume this is an oversight -- this sort of thing would be probably less likely to happen if arguments were explicitly listed. As a final point, it also makes introspection clearer in IDEs.

As you can see, I am not a fan of `*args, **kwargs` unless it *must* be used. If `CanvasBackend` allows a variable number of arguments, it would have to stay, but I don't think it does...?