Not sure why you think this would make that less flexible.
It's just a factory, which can be a Lambda.
@Inject
MySkin(Control c, OtherStuff os) { }
Have the injector framework provide you with an assisted injected
function/factory:
Function<Control, MySkin> assistedFactory; // takes a control,
instantiates MySkin
(or do the above manually if your framework of choice can't do this)
Then you can still call installSkin like:
control.installSkin(assistedFactory::apply);
Not to mention you're free to provide anything else that results in a Skin:
control.installSkin(c -> {
...
});
All of what you mention is still possible AFAICS.
--John
On 22/07/2022 18:44, Michael Strauß wrote:
While it would be a little bit clearer, this idea also limits the
flexibility of the API.
For example, users might want to pass dependencies into skin
instances, or construct skin instances with a factory.
I think it's good enough when controls detect that a skin instance is
set on a different control than the one for which is was constructed.
On Fri, Jul 22, 2022 at 12:49 AM John Hendrikx <john.hendr...@gmail.com> wrote:
Hi Andy,
Was a single step install process considered, something like:
control.installSkin(MySkin::new);
This would also make it much more clear that Skins are single use only, where
the API currently has to bend over backwards to make that clear and enforce it.
Other than that, I think your suggestion would be a definite improvement over
the current situation. Something never felt quite right about how skins where
set up and attached to controls, it felt fragile and cumbersome -- possibly as
the result of relying on a writable property as the means to install a skin.
--John
