linebender/druid

Decouple piet and druid-shell

Open

#1 924 ouverte le 16 août 2021

Voir sur GitHub
 (8 commentaires) (1 réaction) (0 assignés)Rust (567 forks)batch import
architecturehelp wanted

Métriques du dépôt

Stars
 (9 091 stars)
Métriques de merge PR
 (Aucune PR mergée en 30 j)

Description

It is not currently possible to use druid-shell without using piet, and I think this is an unnecessary coupling, and it makes druid-shell strictly less useful.

I would like to move all of the piet-specific code from druid-shell into druid. In practice this means:

  • Any shared PietText objects should live somewhere in druid (unclear where, exactly, druid doesn't really have an application-global object? maybe the AppHandler?)
  • instead of passing a RenderContext to the paint method, druid-shell should pass a window handle
  • druid should construct the RenderContext itself, from the window handle

This does violate the principal that platform-specific code should generally be in druid-shell instead of druid. Is there a viable alternative? I'm not sure if there's a good one, although we could perhaps have a from_raw_handle(handle: &RawWindowHandle) -> RenderContext method in piet-common? I'm not sure if this really makes a ton of sense, but it's an option?

If someone is interested in taking this on, I am happy to answer questions.

Guide contributeur

Direction de recherche
Étudier où les objets PietText sont actuellement utilisés dans druid shell et comment ils sont partagés. Examiner la modification de la méthode paint pour passer un handle de fenêtre au lieu d'un RenderContext, puis construire le RenderContext dans druid à partir de ce handle. Considérer l'alternative d'ajouter une méthode from raw handle à piet common. Examiner les commentaires de l'issue pour toute considération de conception supplémentaire.
Stack technique
rust
Domaine
frontend
Type d'issue
Refactorisation
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
3
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
3-5 jours
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Plutôt claire
Prérequis
Rust
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
30