linebender/druid

Decouple piet and druid-shell

Open

#1.924 geöffnet am 16. Aug. 2021

Auf GitHub ansehen
 (8 Kommentare) (1 Reaktion) (0 zugewiesene Personen)Rust (567 Forks)batch import
architecturehelp wanted

Repository-Metriken

Stars
 (9.091 Stars)
PR-Merge-Metriken
 (Keine gemergten PRs in 30 T)

Beschreibung

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.

Contributor Guide

Research-Richtung
Untersuchen, wo PietText Objekte derzeit in druid shell verwendet werden und wie sie geteilt werden. Erforschen, die paint Methode so zu ändern, dass sie ein Fenster Handle anstelle eines RenderContext übergibt, und dann den RenderContext in druid aus diesem Handle zu konstruieren. Die Alternative in Betracht ziehen, eine from raw handle Methode zu piet common hinzuzufügen. Die Issue Kommentare auf zusätzliche Design Überlegungen überprüfen.
Tech Stack
rust
Domain
frontend
Issue Type
Refactoring
SchwierigkeitGeschätzte Implementierungsschwierigkeit für neue Contributors, von 1 für sehr kleine Änderungen bis 5 für Expertenarbeit.
3
Geschätzte ZeitEin grober Zeitrahmen, um zu recherchieren, zu implementieren, zu testen und einen Pull Request vorzubereiten.
3-5 Tage
AktivitätsstatusWie verfügbar das Issue gerade wirkt: frisch, aktiv, stale, blockiert oder wartet auf Maintainer-Input.
Aktiv
KlarheitWie klar das Issue die erwartete Änderung, Akzeptanzkriterien und den nächsten Schritt erklärt.
Meist klar
Voraussetzungen
Rust
EinsteigerfreundlichkeitEin Score von 1 bis 100, der schätzt, wie zugänglich dieses Issue für First-Time Contributors ist.
30