Skip to content
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

Custom widgets #16

Closed
dhardy opened this issue Dec 3, 2019 · 2 comments
Closed

Custom widgets #16

dhardy opened this issue Dec 3, 2019 · 2 comments

Comments

@dhardy
Copy link
Collaborator

dhardy commented Dec 3, 2019

Custom widget implementations need to define several details. It turns out this is not trivial, though the following provides good inspiration for a design.

Size

The widget should return a SizeRules as e.g. Theme::size_rules. This requires some details, e.g. a draw object (to generate text dimensions), the axis, and the DPI.

Drawing

The question here is over which API should user-implemented widgets do their drawing? Some options:

  • kas::draw::Draw: a fixed draw trait; does not allow themes to influence custom widgets; does not allow direct access to things like wgpu::Device
  • generic draw object with user-specified bounds (e.g. a hypothetical kas_wgpu::DrawWgpu); allows lower-level drawing but still does not allow theme influence; additionally, use of generics will require some redesign of widget traits
  • theme: we could require themes to implement a larger API including things like "draw_button_surface"; this allows higher-level draw operations at the cost of a much bigger Theme API
  • draw trait(s) + theme colour: hybrid approach allowing some theming of custom widgets

Probably the best answer here is the most complex one: extend the Theme trait API and allow direct access to draw traits via generics, along with theme colours.

Alternative (also for size): allow custom widget classes, and use a theme-extension to draw this. This option requires much of the above still: high-level draw operations in the Theme trait, theme colours, access to low-level draw devices.

Event handling

This is covered already by the event::Handler trait (may require tweaking).

Errata

Further details which should be customisable:

  • alignment
  • whether the widget accepts keyboard grabs
@dhardy
Copy link
Collaborator Author

dhardy commented Dec 3, 2019

Providing the custom implementations

We already allow custom widgets (e.g. all make_widget output is a custom widget). We just need the API to specify the details.

Event handling

As noted above, this is already possible via implementation of the parameterised kas::event::Handler trait.

Size + drawing

The straightforward option would be to add Custom(&dyn CustomDrawable) option to kas::class::Class; unfortunately this must be object-safe thus restricts us to the Draw trait defined with kas's core (so not traits from kas_wgpu and not parameterised traits like Theme, although that could possibly be made un-parameterised).

To allow use of parameterised / external APIs, we should instead add draw/size functions to the Widget trait, and allow user implementations.

Misc. functions

Possibly we should move functions like alignments to the Widget trait with a default implementation around the class-provided version (or just drop the class provided version). This implies also that users should be able to implement Widget manually.


Since solutions require modifications to the Widget trait, I will re-open #9.

This was referenced Dec 3, 2019
@dhardy
Copy link
Collaborator Author

dhardy commented Dec 8, 2019

Custom widgets are now possible using the "theme" helpers SizeHandle and DrawHandle (see also this comment). The details of these two traits still need fleshing out, but this merely means adding/tweaking a feature, not a large change.

Exemplar: the CheckBox widget now does not require any special details to implement (besides the theme providing a "checkbox" drawable element; the theme should draw all standard elements with a lower-level draw API available on demand).

@dhardy dhardy closed this as completed Dec 8, 2019
@dhardy dhardy mentioned this issue Dec 8, 2019
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant