cacao
0.4.0-beta2
Cette bibliothèque fournit des liaisons de rouille sûres pour AppKit sur macOS (qualité bêta, assez utilisable) et UIKit sur iOS / TVOS (qualité alpha, voir Repo). Il essaie de le faire d'une manière que, si vous avez fait une programmation pour le cadre avant (dans Swift ou Objective-C), vous vous sentirez familier. Ceci est délicat dans la rouille en raison du modèle de propriété, mais certains codage créatifs et hypothèses peuvent nous rendre assez loin.
Cela existe sur Crates.io en partie pour permettre au projet de voir une utilisation plus large, ce qui peut éclairer le développement. Cela dit, cette bibliothèque est actuellement en début de stades et peut avoir des bogues - votre utilisation est à vos propres risques. Cependant, à condition que vous suiviez les règles (concernant la mémoire / la propriété), il est déjà bien pour certaines applications. Le référentiel de base a une multitude d'exemples pour vous aider à démarrer.
Important
Si vous migrez de 0,2 à 0,3, vous devez élire
appkitouuikitcomme fonctionnalité dans votreCargo.toml. Ce changement a été apporté à la prise en charge des plateformes qui ne sont pas seulement MacOS / IOS / TVOS (par exemple, GnuStep, Airyx). L'une de ces fonctionnalités est nécessaire pour fonctionner;appkitest par défaut pour faciliter le développement.
Notez que cette caisse repose sur l'exécution de l'objectif-C. L'interfaçage avec le temps d'exécution nécessite des blocs dangereux; Cette caisse gère ces interactions dangereuses pour vous et fournit un wrapper sûr, mais en utilisant cette caisse, vous comprenez que l'utilisation de
unsafeest une donnée et sera quelque peu répandue pour les contrôles enveloppés. Cela ne signifie pas que vous ne pouvez pas évaluer, examiner ou remettre en question une utilisation dangereuse - sachez que cela se produit, et en grande partie, cela ne disparaît pas. Les questions relatives à la simple existence de dangereuse seront fermées sans commentaire.
Si vous cherchez à construire les documents pour cela sur votre machine locale, vous voudrez ce qui suit en raison de la façon dont les drapeaux fonctionnaient avec 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 ( ) ;
} Pour des exemples plus approfondis, consultez les examples/ dossiers.
Si vous êtes intéressé par un exemple plus "évier de cuisine", consultez la todos_list avec:
cargo run --example todos_list En raison de la façon dont les programmes AppKit et Uikit fonctionnent généralement, vous êtes encouragé à faire la majeure partie de votre travail à partir de la méthode did_finish_launching() de votre AppDelegate . Cela garantit que l'application a eu le temps d'initialiser et de faire tout l'entretien ménager nécessaire dans les coulisses.
En termes de pièces principalement de travail, le tableau ci-dessous présente le niveau de support pour les caractéristiques variables. Cette liste n'est pas exhaustive uniquement en vertu de la mise à jour de la documentation étant l'enfer - vous êtes donc encouragé à consulter la documentation du code pour plus d'informations:
Notez que même si iOS a des marques de contrôle vertes, certains composants ne sont toujours pas aussi bien définis (par exemple, les vues / ViewControllers y sont toujours très alpha).
Les plates-formes sans apple qui calent ou fournissent une forme d'AppKit peuvent être en mesure d'utiliser une bonne partie de la prise en charge d'AppKit dans cette bibliothèque.
| Composant | Description | Applaudir | ios | tvos |
|---|---|---|---|---|
| Appliquer | Initialisation et événements | ✅ | ✅ | |
| Fenêtre | Construction, manipulation, événements | ✅ | ✅ | |
| Voir | Construction, style, événements | ✅ | ✅ | |
| ViewController | Construction, événements de cycle de vie | ✅ | ✅ | |
| Couleur | Couleurs soutenues par le système, thème | ✅ | ✅ | |
| ListView | Liste réutilisable avec lignes en cache | ✅ | ||
| Bouton | Style, événements, support de barre d'outils | ✅ | ||
| Étiquette / texte | Rendu et entrée texte | ✅ | ||
| Image / ImageView | Chargement, dessin, etc. | ✅ | ✅ | |
| Barre d'outils | Barre d'outils native de base | ✅ | ||
| SplitViewController | Vues partagées (Big Sur Friendly) | ✅ | ||
| WebView | Wrapper pour wkwebview | ✅ | ||
| Userdefaults | Persistant de petites données | ✅ | ✅ | |
| AutoLayout | Afficher la mise en page pour différents écrans | ✅ | ✅ |
Voici une liste des fonctionnalités de cargaison qui peuvent être activées ou désactivées.
appkit : liens AppKit.framework .uikit : liens UIKit.framework (iOS / TVOS uniquement).cloudkit : lie CloudKit.framework et fournit des emballages autour de la fonctionnalité CloudKit. Actuellement, pas de fonction complète.color_fallbacks : fournit des couleurs de secours pour les systèmes plus anciens où les types de chèques systemColor n'existent pas. Cette fonctionnalité est très rare et vous n'en avez probablement pas besoin.quicklook : lie QuickLook.framework et propose des méthodes de génération d'images d'aperçu pour les fichiers.user-notifications : LIENDS UserNotifications.framework et fournit des fonctionnalités pour émettre des notifications sur MacOS et iOS. Notez que cela nécessite que votre application soit signée de code et ne fonctionnera pas sans elle.webview : Liens WebKit.framework et fournit un contrôle WebView soutenu par WKWebView . Cette fonctionnalité n'est pas prise en charge sur TVOS, car la plate-forme n'a pas de contrôle WebView. Cette fonctionnalité est également potentiellement prise en charge uniquement pour MacOS / IOS en raison du contrôle WKWebView et du support variable sur les plates-formes non appletes.webview-downloading-macos : permet de télécharger des fichiers à partir de la WebView via une interface privée. Ce n'est pas une fonctionnalité d'application-magasin, alors sachez cela avant de l'activer. Cette fonctionnalité n'est pas prise en charge sur iOS (un utilisateur gérerait les téléchargements très différemment) ou TVOS (il n'y a pas du tout du navigateur Web). Pourquoi ne pas étendre la caisse de cacao-RS existante?
Une bonne question. À la fin de la journée, cette caisse (je crois, et quelqu'un peut me corriger si je me trompe) est quelque peu liée à Servo, et je voulais expérimenter la meilleure approche pour représenter le modèle d'interface utilisateur de cacao à Rust. Cette caisse n'ignore pas entièrement leur travail non plus - core_foundation et core_graphics sont utilisés en interne et réexportés pour une utilisation générale.
Pourquoi devrais-je écrire en rouille plutôt qu'en langue x?
Dans mon cas, je veux pouvoir écrire des applications natives pour mes appareils (et la plate-forme pour laquelle je aime créer des produits) sans être enfermé dans l'écriture dans des langages spécifiques à Apple ... et sans écrire en C / C ++ ou JavaScript (Remarque: La chaîne d'outils , pas la langue - ES6 / TypeScript est très bien). Je veux faire cela parce que je suis fatigué de frapper une montagne de travail quand je veux porter mes applications vers d'autres écosystèmes. Je pense que Rust offre un modèle viable (en croissance mais significatif) pour partager le code sur les plateformes et les écosystèmes sans sacrifier les performances.
(C'est la partie où Internet s'allume et se déchaîne à propos d'une combinaison d'électron, de QT, etc. - nous ne nous soucions pas ici car il est battu à mort ailleurs)
Cette caisse est utile pour les personnes qui n'ont pas besoin d'aller tout-in sur l'écosystème Apple, mais qui veulent y porter leur travail avec une certaine facilité relative. On ne s'attend pas à ce que tout le monde veuille soudainement réécrire ses applications macOS / iOS / TVOS à Rust.
Objective-C n'est-il pas mort?
Oui et non.
Il est vrai qu'Apple favorise définitivement Swift, et pour une bonne raison (et je dis cela en tant qu'amant sans vergogne de Objective-C). Cela dit, je serais surpris si nous n'avions pas plus de 5 ans et plus de soutien; Apple est rapide à déprécier, mais la suppression de l'exécution de l'objectif-C nécessiterait une tonne de temps et d'efforts. Peut-être que Swiftui le tue, qui sait. Un emballage autour de ce truc devrait en théorie faciliter la balange du backend d'interface utilisateur sous-jacent chaque fois que vient le temps.
Une chose à noter est qu'Apple a commencé à publier des cadres Swift uniquement. Pour les cas où vous en avez besoin, il devrait être possible de faire une combinaison de liaison et de pontage - ce qui informerait comment l'échange du backend d'interface utilisateur sous-jacent se produirait à un moment donné.
Certains pourraient également dénoncer l'objectif-C comme lent. À cela, je noterais ce qui suit:
TL; DR c'est probablement bien, et vous avez de la rouille pour vos besoins de performance.
Pourquoi ne pas simplement envelopper Uikit, puis compter sur le catalyseur?
Je n'ai pas encore vu une seule application où Catalyst se sentait bien. L'objectif est bon, cependant, et s'il arrivait à un point où cela semblait être la voie à suivre (par exemple, Apple tue juste Appkit), c'est certainement une option.
Vous ne pouvez pas envelopper tous les comportements spécifiques à la plate-forme ici ...
Correct! Chaque contrôle de l'interface utilisateur contient un champ objc , que vous pouvez utiliser comme trappe d'évacuation - si le contrôle ne prend pas en charge quelque chose, vous êtes libre de passer à l'objectif-C Runtime vous-même et de le gérer.
Pourquoi n'utilisez-vous pas les liaisons pour générer automatiquement ce genre de choses?
À des fins d'exploration initiales, j'ai fait la majeure partie de cela à la main, car je voulais trouver une approche qui s'adapte bien dans le modèle de rouille avant de s'engager dans la génération de liaison. C'est quelque chose sur lequel je me concentrerai probablement maintenant que j'ai des choses "qui fonctionnent" assez bien.
Est-ce lié à Cacao, le projet Swift?
Non. Le projet mentionné dans cette question visait à cartographier des parties de Cocoa et Uikit pour fonctionner sur Linux, mais n'a pas vu l'activité depuis un certain temps (c'était vraiment cool aussi!).
La dénomination du projet open source en 2020, c'est comme essayer d'acheter un domaine .com : tout ce qui est bon est pris. Heureusement, plusieurs projets peuvent partager un nom ... c'est donc ce qui va se passer ici.
Est-ce que ce genre de tromperie le modèle d'objet Rust?
Cela dépend de la façon dont vous le regardez. Personnellement, je m'en fiche trop - la couche GUI de ces plates-formes est difficile à soutenir pour certaines classes de produits, et leur abandonner signifie également abandonner des outils testés au combat pour des choses comme l'accessibilité et l'intégration plus profonde du système d'exploitation. Cela dit, en interne, il y a des efforts pour essayer de faire en sorte que les choses respectent le modèle de Rust sur la façon dont les choses devraient fonctionner.
Vous pouvez considérer cela comme similaire à GTK-RS. Si vous souhaitez soutenir ou essayer un modèle plus pur , allez voir Druid ou quelque chose. :)
Dual sous licence sous une licence MIT / MPL-2.0. Voir les fichiers appropriés dans ce référentiel pour plus d'informations. Apple, Appkit, Uikit, Cocoa et d'autres marques sont Copyright Apple, Inc.
Vous pouvez me suivre sur Twitter ou m'envoyer un e-mail avec des questions qui ne correspondent pas à un problème ici.
