cacao
0.4.0-beta2
Esta biblioteca proporciona enlaces de óxido seguros para AppKit en macOS (calidad beta, bastante utilizable) y UIKit en iOS/TVOS (calidad alfa, ver repose). Intenta hacerlo de una manera que, si ha realizado programación para el marco antes (en Swift u Objective-C), se sienta familiar. Esto es complicado en la óxido debido al modelo de propiedad, pero algunas codificaciones creativas y suposiciones pueden llevarnos bastante lejos.
Esto existe en cajas.io en parte para permitir que el proyecto vea un uso más amplio, que puede informar el desarrollo. Dicho esto, esta biblioteca es actualmente las primeras etapas y puede tener errores: su uso es bajo su propio riesgo. Sin embargo, siempre que siga las reglas (con respecto a la memoria/propiedad) ya está bien para algunas aplicaciones. El repositorio central tiene una gran cantidad de ejemplos para ayudarlo a comenzar.
Importante
Si está migrando de 0.2 a 0.3, debe elegir
appkitouikitcomo una característica en suCargo.toml. Este cambio se realizó para admitir plataformas que no son solo macOS/iOS/TVOS (por ejemplo, Gnustep, Airyx). Se requiere una de estas características para trabajar;appkitestá predeterminado para facilitar el desarrollo.
Tenga en cuenta que esta caja se basa en el tiempo de ejecución Objective-C. La interfaz con el tiempo de ejecución requiere bloques inseguros; Esta caja maneja esas interacciones inseguras para usted y proporciona un envoltorio seguro, pero al usar esta caja comprende que el uso de
unsafees un hecho y será algo rampante para los controles envueltos. Esto no significa que no pueda evaluar, revisar o cuestionar un uso inseguro, solo saber que está sucediendo, y en gran parte no va a desaparecer. Los problemas relacionados con la mera existencia de inseguros se cerrarán sin comentarios.
Si está buscando construir los documentos para esto en su máquina local, querrá lo siguiente debido a la forma en que funcionan las banderas de funciones con 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 obtener ejemplos más exhaustivos, consulte los examples/ carpeta.
Si está interesado en un ejemplo de "fregadero de cocina", consulte el toDos_list con:
cargo run --example todos_list Debido a la forma en que los programas AppKit y Uikit generalmente funcionan, se le recomienda hacer la mayor parte de su trabajo a partir del método did_finish_launching() de su AppDelegate . Esto asegura que la aplicación haya tenido tiempo de inicializar y hacer cualquier limpieza necesaria detrás de escena.
En términos de piezas principalmente de trabajo, la siguiente tabla muestra el nivel de soporte para características variables. Esta lista no es exhaustiva solo en virtud de que la actualización de la documentación sea el infierno, por lo que se le recomienda ver la documentación construida por código para obtener más información:
Tenga en cuenta que si bien iOS tiene marcas de verificación verdes, algunos componentes aún no están tan bien definidos (por ejemplo, vistas/ViewControllers todavía están muy alfa allí).
Las plataformas que no son de Apple que cuan o proporcionan una forma de AppKit pueden usar una buena parte del soporte de AppKit en esta biblioteca.
| Componente | Descripción | Appkit | iOS | tvos |
|---|---|---|---|---|
| Aplicación | Inicialización y eventos | ✅ | ✅ | |
| Ventana | Construcción, manejo, eventos | ✅ | ✅ | |
| Vista | Construcción, estilo, eventos | ✅ | ✅ | |
| ViewController | Construcción, eventos de ciclo de vida | ✅ | ✅ | |
| Color | Colores respaldados por el sistema, temas | ✅ | ✅ | |
| Listview | Lista reutilizable con filas en caché | ✅ | ||
| Botón | Estilo, eventos, soporte de barra de herramientas | ✅ | ||
| Etiqueta/Textfield | Renderización e entrada de texto | ✅ | ||
| Image/ImageView | Carga, dibujo, etc. | ✅ | ✅ | |
| Barra de herramientas | Barra de herramientas nativas básicas | ✅ | ||
| SplitViewController | Vistas divididas (Big Sur Friendly) | ✅ | ||
| Webview | Envoltura para wkwebview | ✅ | ||
| Deventa de usuarios | Persistiendo pequeños datos | ✅ | ✅ | |
| Autolayout | Ver diseño para pantallas variables | ✅ | ✅ |
Las siguientes son una lista de funciones de carga que se pueden habilitar o deshabilitar.
appkit : Enlace AppKit.framework .uikit : enlaces UIKit.framework (solo iOS/TVOS).cloudkit : Links CloudKit.framework y proporciona algunos envoltorios alrededor de la funcionalidad CloudKit. Actualmente no presenta una característica completa.color_fallbacks : proporciona colores respaldo para sistemas más antiguos donde los tipos systemColor no existen. Esta característica es muy poco común y probablemente no la necesite.quicklook : Enlace QuickLook.framework y ofrece métodos para generar imágenes de vista previa para archivos.user-notifications : Enlace UserNotifications.framework y proporciona funcionalidad para emitir notificaciones en MacOS e iOS. Tenga en cuenta que esto requiere que su aplicación esté firmada por código y no funcionará sin ella.webview : Enlace WebKit.framework y proporciona un control WebView respaldado por WKWebView . Esta función no es compatible con TVOS, ya que la plataforma no tiene control WebView. Esta característica también es potencialmente compatible para MACOS/IOS debido al control WKWebView y un soporte variable en plataformas que no son de Apple.webview-downloading-macos : habilita la descarga de archivos desde la WebView a través de una interfaz privada. Esta no es una característica segura para la tienda de aplicaciones, así que tenga en cuenta eso antes de habilitar. Esta característica no es compatible con iOS (un usuario manejaría las descargas de manera muy diferente) o TVOS (no hay un navegador web en absoluto). ¿Por qué no extender la caja de cacao-RS existente?
Una buena pregunta. Al final del día, esa jaula (creo, y alguien puede corregirme si me equivoco) está algo vinculada al servo, y quería experimentar con cuál era el mejor enfoque para representar el modelo de interfaz de usuario de cacao en Rust. Esta caja tampoco ignora su trabajo por completo: core_foundation y core_graphics se usan internamente y se reexportan para uso general.
¿Por qué debería escribir en óxido, en lugar de x lenguaje?
En mi caso, quiero poder escribir aplicaciones nativas para mis dispositivos (y la plataforma para la que me gusta crear productos) sin estar bloqueado para escribir en idiomas específicos de Apple ... y sin escribir en C/C ++ o JavaScript (nota: la cadena de herramientas , no el idioma - ES6/TypeScript está bien). Quiero hacer esto porque estoy cansado de golpear una montaña de trabajo cuando quiero transferir mis aplicaciones a otros ecosistemas. Creo que Rust ofrece un modelo (creciente pero significativo) viable para compartir código en plataformas y ecosistemas sin sacrificar el rendimiento.
(Esta es la parte en la que Internet se ilumina y se queja de alguna combinación de electrones, QT, etc., no nos molestamos aquí, ya que es golpeado hasta la muerte en otra parte)
Esta jaula es útil para las personas que no necesitan ir todo en el ecosistema de Apple, pero desean transferir su trabajo allí con cierta facilidad relativa. No se espera que todos de repente quieran reescribir sus aplicaciones MacOS/iOS/TVOS en Rust.
¿No está muerto Objective-C?
Sí, y no.
Es cierto que Apple definitivamente favorece a Swift, y por una buena razón (y digo esto como un amante descarado de Objective-C). Dicho esto, me sorprendería si no tuviéramos otros ~ más de 5 años de apoyo; Apple se desprecia rápidamente, pero eliminar el tiempo de ejecución de objetivos-C requeriría un montón de tiempo y esfuerzo. Tal vez Swiftui lo mata, quién sabe. Un envoltorio alrededor de estas cosas debe hacer que sea más fácil cambiar el backend subyacente de la interfaz de usuario siempre que llegue el momento.
Una cosa a tener en cuenta es que Apple ha comenzado a lanzar marcos solo Swift. Para los casos en los que los necesite, debería ser posible hacer una combinación de vinculación y puente, lo que informaría cómo el intercambio de la interfaz de usuario subyacente ocurriría en algún momento.
Algunos también podrían denunciar el objetivo-C como lento. A eso, notaría lo siguiente:
tl; dr probablemente esté bien, y tienes óxido para tus necesidades de rendimiento.
¿Por qué no solo envolver a Uikit y luego confiar en Catalyst?
Todavía tengo que ver una sola aplicación donde Catalyst se sintió bien. Sin embargo, el objetivo es bueno, y si llegó a un punto en el que eso parecía el camino a seguir (por ejemplo, Apple solo mata a Appkit), entonces es sin duda una opción.
No puede envolver todo el comportamiento específico de la plataforma aquí ...
¡Correcto! Cada control de la interfaz de usuario contiene un campo objc , que puede usar como escotilla de escape: si el control no admite algo, usted es libre de caer en el tiempo de ejecución Objective -C usted mismo y manejarlo.
¿Por qué no usa enlaces para generar automáticamente estas cosas?
Para fines de exploración iniciales, he hecho la mayor parte de esto a mano, ya que quería encontrar un enfoque que se ajuste bien al modelo de óxido antes de comprometerme con la generación vinculante. Esto es algo en lo que probablemente me centraré en el siguiente ahora que tengo cosas "funcionando" lo suficientemente bien.
¿Está esto relacionado con Cacao, el proyecto Swift?
No. El proyecto mencionado en esta pregunta tenía como objetivo mapear porciones de Cocoa y Uikit para ejecutarse en Linux, pero no ha visto actividad en algún tiempo (¡también fue realmente genial!).
El nombre del proyecto de código abierto en 2020 es como tratar de comprar un dominio .com : todo lo bueno se toma. Afortunadamente, varios proyectos pueden compartir un nombre ... así que eso es lo que va a pasar aquí.
¿No es este tipo de engañar al modelo de objeto de óxido?
Depende de cómo lo mires. Personalmente, no me importa demasiado: la capa de GUI para estas plataformas es un requisito difícil para apoyar ciertas clases de productos, y renunciar también significa renunciar a herramientas probadas en batalla para cosas como accesibilidad e integración más profunda del sistema operativo. Dicho esto, internamente hay esfuerzos para tratar de hacer que las cosas respeten el modelo de Rust de cómo deberían funcionar las cosas.
Puedes pensar en esto como similar a GTK-RS. Si desea admitir o probar un modelo más puro , visite Druid o algo así. :)
Dual con licencia bajo una licencia MIT/MPL-2.0. Consulte los archivos apropiados en este repositorio para obtener más información. Apple, Appkit, Uikit, Cocoa y otras marcas registradas son Copyright Apple, Inc.
Puede seguirme en Twitter o enviarme un correo electrónico con preguntas que no se ajusten a un problema aquí.
