What about abstracting widgets' rendering

[stephanemagnenat]

Hello,

Currently, in iced the renderer is abstract and widgets are styled, but nonetheless the drawing code is fixed. If we consider the button, for example, it is explicitly rendered as a quad (button.rs:312) and the shadow is manually hacked through an offset quad. However, if one would like to use iced for a game, one might want a button made of 9 pieces textures (4 corners, non-stretched; 4 sides, stretched in 1D; 1 center, stretched in 2D). Moreover, if the renderer can render proper shadows in a shader, one might not want to use the shifted-rectangle hack.

Hence, my idea/question is the following: is there a desire or plan to add one layer of abstraction for rendering widgets? It could be a trait (such as ButtonRenderer or ButtonDrawer that implements more semantic functions, e.g. renderBackground or renderShadow) that is specific to each widget. That would allow to reuse the widget logic with a completely different visual style, and possibly better performance by matching the abilities to the underlying renderer more closely.

What do you think?

[hecrj]

This was possible before and I ended up removing the abstraction layer completely in #1110.

Instead of an additional rendering abstraction, I believe we should make widget logic reusable. So, if users want to implement their own Button widget, they can do so by reusing some of the logic of the built-in one.

[hecrj]

@stephanemagnenat It turns out that reusable widget logic is something I just needed for my exploration in the virtual-widgets branch.

Here is an example of what it could look like: ecb3df8. Basically, the button module will expose reusable update, draw, layout, and mouse_interaction functions to allow users to reuse the logic they prefer.

[stephanemagnenat]

Thank you for your fast and detailed answer! Reusing widget logic sounds good!

One question though: in ecb3df8, the button still has a fill_quad in its draw method. When reused, how is this call supposed to be abstracted away? Is it by simply not calling the original draw method?