cacao
0.4.0-beta2
Esta biblioteca fornece ligações de ferrugem seguras para AppKit no MacOS (qualidade beta, bastante utilizável) e UIKit no iOS/TVOS (qualidade alfa, consulte o repositório). Ele tenta fazê-lo de uma maneira que, se você fez programação para a estrutura antes (em Swift ou Objective-C), parecerá familiar. Isso é complicado na ferrugem devido ao modelo de propriedade, mas algumas codificações e suposições criativas podem nos levar muito longe.
Isso existe em Crates.io em parte para permitir que o projeto consulte um uso mais amplo, o que pode informar o desenvolvimento. Dito isto, esta biblioteca está atualmente em estágios iniciais e pode ter bugs - seu uso é por sua conta e risco. No entanto, desde que você siga as regras (em relação à memória/propriedade), já está bem para alguns aplicativos. O repositório principal tem uma riqueza de exemplos para ajudá -lo a começar.
Importante
Se você estiver migrando de 0,2 para 0,3, ele deve eleger
appkitouuikitcomo um recurso em suaCargo.toml. Essa alteração foi feita para suportar plataformas que não são apenas MacOS/iOS/TVOS (por exemplo, Gnustep, Airyx). Um desses recursos é necessário para funcionar;appkité padronizado para facilitar o desenvolvimento.
Observe que esta caixa se baseia no tempo de execução do Objective-C. A interface com o tempo de execução requer blocos inseguros; Essa caixa lida com essas interações inseguras para você e fornece um invólucro seguro, mas, ao usar essa caixa, você entende que o uso de
unsafeé um dado e será um pouco desenfreado para controles embrulhados. Isso não significa que você não pode avaliar, revisar ou questionar o uso inseguro - apenas saiba que está acontecendo e, em grande parte, não está desaparecendo. Questões referentes à mera existência de inseguras serão fechadas sem comentar.
Se você deseja construir os documentos para isso em sua máquina local, desejará o seguinte devido à maneira como os sinalizadores de recursos funcionam com cargo doc :
RUSTDOCFLAGS="--cfg docsrs" cargo +nightly doc --all-features --open
use cacao :: appkit :: { App , AppDelegate } ;
use cacao :: appkit :: window :: Window ;
# [ derive ( Default ) ]
struct BasicApp {
window : Window
}
impl AppDelegate for BasicApp {
fn did_finish_launching ( & self ) {
self . window . set_minimum_content_size ( 400. , 400. ) ;
self . window . set_title ( "Hello World!" ) ;
self . window . show ( ) ;
}
}
fn main ( ) {
App :: new ( "com.hello.world" , BasicApp :: default ( ) ) . run ( ) ;
} Para exemplos mais completos, verifique os examples/ pasta.
Se você estiver interessado em um exemplo mais "pia da cozinha", confira o Todos_list com:
cargo run --example todos_list Devido à maneira como os programas Appkit e Uikit normalmente funcionam, você é incentivado a fazer a maior parte do seu trabalho a partir do método did_finish_launching() do seu AppDelegate . Isso garante que o aplicativo tenha tempo para inicializar e fazer qualquer limpeza necessária nos bastidores.
Em termos de peças de trabalho principalmente, a tabela abaixo mostra o nível de suporte para recursos variados. Esta lista não é exaustiva apenas em virtude da atualização da documentação, então você é incentivado a conferir a documentação criada pelo código para obter mais informações:
Observe que, embora o iOS tenha marcas de verificação verdes, alguns componentes ainda não estão tão bem definidos (por exemplo, as vistas/viewcontrollers ainda estão muito alfa lá).
Plataformas que não são de manchas que Shim ou fornecem uma forma de Appkit podem usar uma boa parte do suporte Appkit nesta biblioteca.
| Componente | Descrição | Appkit | iOS | TvOS |
|---|---|---|---|---|
| App | Inicialização e eventos | ✅ | ✅ | |
| Janela | Construção, manuseio, eventos | ✅ | ✅ | |
| Visualizar | Construção, estilo, eventos | ✅ | ✅ | |
| ViewController | Construção, eventos do ciclo de vida | ✅ | ✅ | |
| Cor | Cores apoiadas pelo sistema, temas | ✅ | ✅ | |
| ListView | Lista reutilizável com linhas em cache | ✅ | ||
| Botão | Estilo, eventos, suporte da barra de ferramentas | ✅ | ||
| Rótulo/campo de texto | Renderização e entrada de texto | ✅ | ||
| Image/ImageView | Carregando, desenho, etc. | ✅ | ✅ | |
| Barra de ferramentas | Barra de ferramentas nativas básicas | ✅ | ||
| SplitViewController | Vistas divididas (Big Sur amigável) | ✅ | ||
| WebView | Invólucro para wkwebview | ✅ | ||
| UserDefaults | Persistindo pequenos dados | ✅ | ✅ | |
| AUTOLAYOUT | Veja o layout para telas variadas | ✅ | ✅ |
A seguir, é apresentada uma lista de recursos de carga que podem ser ativados ou desativados.
appkit : links AppKit.framework .uikit : links UIKit.framework (somente iOS/tvOS).cloudkit : links CloudKit.framework e fornece alguns invólucros em torno da funcionalidade CloudKit. Atualmente não é o recurso completo.color_fallbacks : fornece cores de fallback para sistemas mais antigos, onde os tipos systemColor não existem. Esse recurso é muito incomum e você provavelmente não precisa dele.quicklook : links QuickLook.framework e oferece métodos para gerar imagens de visualização para arquivos.user-notifications : links UserNotifications.framework e fornece funcionalidade para emitir notificações no macOS e iOS. Observe que isso exige que seu aplicativo seja assinado por código e não funcionará sem ele.webview : links WebKit.framework e fornece um controle WebView apoiado pela WKWebView . Esse recurso não é suportado no TVOS, pois a plataforma não possui controle da WebView. Esse recurso também é potencialmente suportado apenas para o MacOS/iOS devido ao controle WKWebView e suporte variável em plataformas que não são de apple.webview-downloading-macos : permite baixar arquivos do WebView por meio de uma interface privada. Este não é um recurso seguro para armazenamento, portanto, esteja ciente disso antes de ativar. Esse recurso não é suportado no iOS (um usuário lida com downloads de maneira muito diferente) ou TVOS (não há navegador da Web lá). Por que não estender a caixa de cacau-rs existente?
Uma boa pergunta. No final das contas, essa caixa (acredito, e alguém pode me corrigir se estiver errado) está um pouco ligada ao servo, e eu queria experimentar qual era a melhor abordagem para representar o modelo de interface do usuário de cacau na ferrugem. Esta caixa não ignora completamente seu trabalho - core_foundation e core_graphics são usados internamente e reexportados para uso geral.
Por que eu deveria escrever em ferrugem, em vez de X linguagem?
No meu caso, quero poder escrever aplicativos nativos para meus dispositivos (e a plataforma para a qual gosto de construir produtos) sem estar bloqueado para escrever em idiomas específicos da Apple ... e sem escrever em C/C ++ ou JavaScript (Nota: a cadeia de ferramentas , não o idioma - es6/tipyscript). Quero fazer isso porque estou cansado de bater em uma montanha de trabalho quando quero portar meus aplicativos para outros ecossistemas. Eu acho que Rust oferece um modelo (crescente, mas significativo) viável para compartilhar código entre plataformas e ecossistemas sem sacrificar o desempenho.
(Esta é a parte em que a Internet acende e reclama sobre alguma combinação de elétron, qt e assim por diante - não estamos incomodando aqui, pois é espancado até a morte em outros lugares)
Esta caixa é útil para pessoas que não precisam ir ao ecossistema da Apple, mas querem portar seu trabalho para lá com alguma facilidade. Não é esperado que todos queiram de repente reescrever seus aplicativos MacOS/iOS/TvOS em Rust.
O objetivo não está morto?
Sim, e não.
É verdade que a Apple definitivamente favorece o Swift e, por boas razões (e eu digo isso como um amante descarado do Objective-C). Com isso dito, eu ficaria surpreso se não tivéssemos mais ~ 5 anos de apoio; A Apple é rápida em depreciar, mas a remoção do tempo de execução do Objective-C exigiria muito tempo e esforço. Talvez Swiftui mate, quem sabe. Um invólucro em torno dessas coisas deve facilmente facilitar a troca no back -end subjacente da interface do usuário sempre que chegar a hora.
Uma coisa a observar é que a Apple começou a lançar estruturas somente Swift. Para os casos em que você precisa deles, deve ser possível fazer alguma combinação de vinculação e ponte - o que informaria como a troca do back -end subjacente da interface do usuário aconteceria em algum momento.
Alguns também podem descrever o objetivo-C como lento. Para isso, eu observaria o seguinte:
TL; DR provavelmente está bem, e você tem ferrugem para suas necessidades de desempenho.
Por que não apenas embrulhar o Uikit e depois confiar no catalisador?
Ainda não vi um único aplicativo onde o catalisador parecia bom. O objetivo é bom, porém, e se chegou a um ponto em que isso parecia o caminho a seguir (por exemplo, a Apple apenas mata o Appkit), então é certamente uma opção.
Você não pode envolver todo o comportamento específico da plataforma aqui ...
Correto! Cada controle da interface do usuário contém um campo objc , que você pode usar como uma escotilha de fuga - se o controle não suportar algo, você estará livre para cair para o Objective -C Runtime você mesmo e lidar com isso.
Por que você não usa ligações para gerar automaticamente essas coisas?
Para fins de exploração iniciais, fiz a maior parte disso manualmente, pois queria encontrar uma abordagem que se encaixe bem no modelo de ferrugem antes de me comprometer com a geração de ligação. Isso é algo que provavelmente focarei agora que tenho as coisas "funcionando" bem o suficiente.
Isso está relacionado ao cacau, o projeto SWIFT?
Não. O projeto referido nesta pergunta teve como objetivo mapear partes do cacau e do UIKIT para correr no Linux, mas não viu atividades há algum tempo (também foi muito legal!).
O projeto de código aberto Nomeação em 2020 é como tentar comprar um domínio .com : tudo de bom é tomado. Felizmente, vários projetos podem compartilhar um nome ... Então é isso que vai acontecer aqui.
Isso não está trapaceando o modelo de objeto de ferrugem?
Depende de como você olha para ele. Pessoalmente, não me importo muito - a camada GUI para essas plataformas é um requisito difícil de apoiar determinadas classes de produtos, e desistir delas também significa desistir de ferramentas testadas por batalha para coisas como acessibilidade e integração mais profunda do sistema operacional. Com isso dito, internamente, há esforços para tentar fazer as coisas respeitarem o modelo de Rust de como as coisas devem funcionar.
Você pode pensar nisso como GTK-RS. Se você deseja apoiar ou experimentar um modelo mais puro , vá conferir Druid ou algo assim. :)
Dual Licensed sob uma licença MIT/MPL-2.0. Veja os arquivos apropriados neste repositório para obter mais informações. Apple, Appkit, Uikit, Cacau e outras marcas comerciais são Copyright Apple, Inc.
Você pode me seguir no Twitter ou me enviar um e -mail com perguntas que não se encaixam como um problema aqui.
