linebender/druid

Decouple piet and druid-shell

Open

#1.924 aberto em 16 de ago. de 2021

Ver no GitHub
 (8 comments) (1 reaction) (0 assignees)Rust (567 forks)batch import
architecturehelp wanted

Métricas do repositório

Stars
 (9.091 stars)
Métricas de merge de PR
 (Nenhuma PRs mesclada em 30d)

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.

Guia do colaborador

Direção de pesquisa
Investigar onde os objetos PietText são atualmente usados no druid shell e como são compartilhados. Analisar a modificação do método paint para passar um handle de janela em vez de um RenderContext, e então construir o RenderContext no druid a partir desse handle. Considerar a alternativa de adicionar um método from raw handle ao piet common. Revisar os comentários da issue para quaisquer considerações de design adicionais.
Pilha de tecnologia
rust
Domain
frontend
Tipo Issue
Refatoração
DifficultyDificuldade de implementação estimada para um novo contribuidor, de 1 para alterações muito pequenas a 5 para trabalho de nível especializado.
3
Tempo estimadoUm intervalo de tempo aproximado para um colaborador experiente investigar, implementar, testar e preparar um pull request.
3-5 dias
Status da atividadeQuão disponível o issue aparece agora: novo, ativo, obsoleto, bloqueado ou aguardando entrada do mantenedor.
Ativo
ClarityCom que clareza o issue explica a mudança esperada, os critérios de aceitação e a próxima etapa.
Principalmente claro
Prerequisites
Rust
Simpatia para novatosUma pontuação de 1 a 100 que estima o quão acessível este issue é para colaboradores iniciantes.
30