cacao -Download - cacao -Quellcode -Download

cacao

Anderer Quellcode

0.4.0-beta2

Herunterladen

Kakao

Diese Bibliothek bietet sichere Rostbindungen für AppKit auf macOS (Beta -Qualität, ziemlich nutzbar) und UIKit auf iOS/tvOS (Alpha -Qualität, siehe Repo). Es versucht, dies so zu tun, dass es sich vertraut anfühlt, wenn Sie das Programmieren für das Framework (in Swift oder Objective-C) vorgenommen haben. Dies ist aufgrund des Eigentumsmodells schwierig im Rost, aber einige kreative Codierung und Annahmen können uns ziemlich weit bringen.

Dies existiert zum Teil in Crapes.io, um das Projekt eine breitere Verwendung zu ermöglichen, was die Entwicklung beeinflussen kann. Trotzdem ist diese Bibliothek derzeit in einem frühen Stadium und kann Fehler haben - Ihre Verwendung ist auf eigenes Risiko. Vorausgesetzt, Sie befolgen die Regeln (in Bezug auf Speicher/Eigentum) jedoch für einige Apps bereits in Ordnung. Das Kern -Repository enthält eine Fülle von Beispielen, die Ihnen helfen, loszulegen.

Wichtig
Wenn Sie von 0,2 auf 0,3 migrieren, sollten Sie entweder appkit oder uikit als Funktion in Ihrer Cargo.toml wählen. Diese Änderung wurde vorgenommen, um Plattformen zu unterstützen, die nicht nur MacOS/iOS/tvOS (z. B. Gn .p, Airyx) sind. Eine dieser Funktionen ist erforderlich, um zu arbeiten. appkit wird zur einfachen Entwicklung standardmäßig.

Beachten Sie, dass diese Kiste auf der Ziel-C-Laufzeit beruht. Die Vernetzung mit der Laufzeit erfordert unsichere Blöcke. Diese Kiste verwaltet diese unsicheren Interaktionen für Sie und bietet eine sichere Verpackung. Wenn Sie diese Kiste verwenden, verstehen Sie jedoch, dass die Verwendung von unsafe selbstverständlich ist und für verpackte Steuerelemente etwas weit verbreitet ist. Dies bedeutet nicht , dass Sie die unsichere Nutzung nicht bewerten, überprüfen oder befragen können - nur wissen, dass es passiert, und zum großen Teil geht es nicht weg. Probleme im Zusammenhang mit der bloßen Existenz von Unsicheren werden ohne Kommentar geschlossen.

Wenn Sie die Dokumente für dies auf Ihrer lokalen Maschine erstellen möchten, möchten Sie Folgendes, da Feature -Flags mit cargo doc funktionieren:

RUSTDOCFLAGS="--cfg docsrs" cargo +nightly doc --all-features --open

Hallo Welt

 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 ( ) ;
}

Ausführliche Beispiele finden Sie in den examples/ den Ordner.

Wenn Sie an einem Beispiel für ein "Küchenspülen" interessiert sind, lesen Sie die Todos_List mit:

cargo run --example todos_list

Initialisierung

Aufgrund der Art und Weise, wie Appkit- und UIKIT -Programme normalerweise funktionieren, werden Sie aufgefordert, den Großteil Ihrer Arbeit aus der Methode did_finish_launching() Ihres AppDelegate zu erledigen. Dies stellt sicher, dass die Bewerbung Zeit hatte, hinter den Kulissen eine Haushaltsführung zu initialisieren und zu erledigen.

Derzeit unterstützt

In Bezug auf hauptsächlich Arbeitsstücke zeigt die folgende Tabelle die Unterstützung für unterschiedliche Merkmale. Diese Liste ist nicht ausführlich, nur weil die Aktualisierung der Dokumentation die Hölle ist.

Beachten Sie, dass iOS zwar grüne Checkmarks hat, einige Komponenten jedoch immer noch nicht so gut definiert sind (z. B. Ansichten/ViewController sind dort immer noch sehr alpha).

Nicht-Apple-Plattformen, die eine Form von Appkit anbieten oder anbieten, können möglicherweise einen guten Teil des Appkit-Supports in dieser Bibliothek verwenden.

Komponente	Beschreibung	Appkit	iOS
App	Initialisierung & Ereignisse	✅	✅
Fenster	Bau, Handhabung, Ereignisse	✅	✅
Sicht	Konstruktion, Styling, Veranstaltungen	✅	✅
ViewController	Konstruktion, Lebenszyklusereignisse	✅	✅
Farbe	Systembützte Farben, Themen	✅	✅
ListView	Wiederverwendbare Liste mit zwischengespeicherten Zeilen	✅
Taste	Styling, Veranstaltungen, Symbolleisteunterstützung	✅
Etikett/Textfeld	Textrendern & Eingabe	✅
Bild/ImageView	Laden, Zeichnen usw.	✅	✅
Symbolleiste	Grundlegende native Symbolleiste	✅
SplitViewController	Split Ansichten (Big Sur freundlich)	✅
WebView	Wrapper für WKWebView	✅
UserDefaults	Kleine Daten bestehen	✅	✅
Autolayout	Layout für unterschiedliche Bildschirme anzeigen	✅	✅

Optionale Funktionen

Im Folgenden finden Sie eine Liste von Frachtfunktionen, die aktiviert oder deaktiviert werden können.

appkit : Links AppKit.framework .
uikit : Links UIKit.framework (nur iOS/tvos).
cloudkit : Links CloudKit.framework und bietet einige Wrapper in Bezug auf CloudKit -Funktionalität. Derzeit nicht abgeschlossen.
color_fallbacks : Bietet Fallback -Farben für ältere Systeme, in denen systemColor -Typen nicht vorhanden sind. Diese Funktion ist sehr ungewöhnlich und Sie brauchen sie wahrscheinlich nicht.
quicklook : Links QuickLook.framework und bietet Methoden zum Generieren von Vorschau -Bildern für Dateien.
user-notifications : Verknüpft UserNotifications.framework . Beachten Sie, dass Ihre Bewerbung mit Code unterzeichnet wird und ohne sie nicht funktioniert.
webview : verlinkt WebKit.framework und bietet eine von WKWebView unterstützte WebView -Steuerung. Diese Funktion wird auf TVOS nicht unterstützt, da die Plattform keine Webview -Steuerung hat. Diese Funktion wird möglicherweise nur für macOS/iOS aufgrund der WKWebView-Steuerung und der unterschiedlichen Unterstützung auf Nicht-Appl-Plattformen möglicherweise nur unterstützt.
webview-downloading-macos : Ermöglicht das Herunterladen von WebView über eine private Oberfläche. Dies ist keine App-Store-Safe-Funktion. Beachten Sie dies, bevor Sie es aktivieren. Diese Funktion wird auf iOS nicht unterstützt (ein Benutzer würde Downloads sehr unterschiedlich behandeln) oder TVOS (dort gibt es überhaupt keinen Webbrowser).

Allgemeine Notizen

Warum nicht die vorhandene Kakao-Rs-Kiste erweitern?
Eine gute Frage. Letztendlich ist diese Kiste (glaube ich, und jemand kann mich korrigieren, wenn ich falsch bin) etwas mit dem Servo verbunden, und ich wollte mit dem, was der beste Ansatz für die Darstellung des Kakao -UI -Modells in Rust war, experimentieren. Diese Kiste ignoriert ihre Arbeit auch nicht vollständig - core_foundation und core_graphics werden intern verwendet und für den allgemeinen Gebrauch erneut exportiert.

Warum sollte ich in Rost und nicht in X -Sprache schreiben?
In meinem Fall möchte ich in der Lage sein, native Anwendungen für meine Geräte (und die Plattform, für die ich gerne Produkte erstellt) zu schreiben, ohne in Apple -spezifische Sprachen zu schreiben ... und ohne in C/C ++ oder JavaScript zu schreiben (Hinweis: Die Toolchain , nicht die Sprache - ES6/Typscript ist in Ordnung). Ich möchte dies tun, weil ich es leid bin, einen Berg der Arbeit zu treffen, wenn ich meine Bewerbungen auf andere Ökosysteme portieren möchte. Ich denke, dass Rust ein (wachsendes, aber bedeutendes) tragfähiges Modell für den Austausch von Code über Plattformen und Ökosysteme teilt, ohne die Leistung zu beeinträchtigen.

(Dies ist der Teil, in dem das Internet aufleuchtet und über eine Kombination aus Elektronen, QT usw. schimpft - wir kümmern uns hier nicht darum, dass es anderswo zu Tode geschlagen wird.)

Diese Kiste ist nützlich für Menschen, die nicht auf das Apple-Ökosystem gehen müssen, aber ihre Arbeit dort mit einiger Leichtigkeit portieren möchten. Es wird nicht erwartet, dass jeder plötzlich seine MacOS/iOS/TVOS -Apps in Rost umschreiben möchte.

Ist Objective-C nicht tot?
Jein.

Es ist wahr, dass Apple aus gutem Grund definitiv Swift bevorzugt (und ich sage dies als unverfrorener Liebhaber von Objective-C). Nachdem dies gesagt ist, wäre ich überrascht, wenn wir keine weitere ~ 5+ Jahre Unterstützung hätten; Apple ist schnell zu veraltet, aber die Entfernung der Ziel-C-Laufzeit würde eine Menge Zeit und Mühe erfordern. Vielleicht tötet Swiftui es, wer weiß. Eine Wrapper um dieses Zeug sollte es möglicherweise leichter machen, das zugrunde liegende UI -Backend auszutauschen, wenn es Zeit ist.

Eine Sache zu beachten ist, dass Apple angefangen hat , reine Rahmenbedingungen zu veröffentlichen. In Fällen, in denen Sie diese benötigen, sollte es möglich sein, eine Kombination aus Verknüpfung und Überbrückung durchzuführen - was darüber informiert wird, wie das Austausch des zugrunde liegenden UI -Backends irgendwann passieren würde.

Einige könnten auch Objektiv-C als langsam entschlüsseln. Dazu würde ich Folgendes bemerken:

Ihr UI -Motor ist wahrscheinlich nicht der Engpass.
Swift ist im Allgemeinen besser, da es eine Klasse von Fehler festlegt, die Objective-C nicht fängt. Zum größten Teil sitzt es ohnehin immer noch auf den vorhandenen Kakao -Frameworks (obwohl diese Aussage nicht gut ~ ~ ~ ~).
Das Versenden von Nachrichten in Objective-C ist optimierter als signifikante Brocken des Code, den Sie schreiben, und ist für die meisten Dinge schnell genug.

TL; DR Es ist wahrscheinlich in Ordnung und Sie haben Rost für Ihre Leistungsbedürfnisse.

Warum nicht einfach Uikit einwickeln und dann auf den Katalysator verlassen?
Ich habe noch keine einzige Anwendung gesehen, in der sich Catalyst gut fühlte. Das Ziel ist jedoch gut, und wenn es zu einem Punkt erreicht wurde, an dem das nur der Weg nach vorne schien (z. B. Apple tötet nur AppKit), dann ist es sicherlich eine Option.

Sie können hier möglicherweise nicht alle plattformspezifischen Verhaltensweisen wickeln ...
Richtig! Jedes UI -Steuerelement enthält ein objc -Feld, das Sie als Escape -Luke verwenden können. Wenn die Steuerung etwas nicht unterstützt, können Sie selbst die Ziel -C -Laufzeit selbst fallen und damit umgehen.

Warum verwenden Sie keine Bindungen, um dieses Zeug automatisch zu generieren?
Zu anfänglichen Erkundungszwecken habe ich das meiste von Hand gemacht, da ich einen Ansatz finden wollte, der gut in das Rust -Modell passt, bevor ich mich zur Bindungsgenerierung verpflichte. Darauf werde ich mich wahrscheinlich als nächstes konzentrieren, da ich Dinge "gut genug" habe.

Haftet dies mit Cacao, dem Swift -Projekt?
Nein. Das in dieser Frage genannte Projekt zielte darauf ab, Teile von Kakao und Uikit auf Linux zu kartieren, hat aber seit einiger Zeit die Aktivität nicht mehr gesehen (es war auch wirklich cool!).

Das Open -Source -Projektnamen im Jahr 2020 ist wie der Versuch, eine .com -Domain zu kaufen: Alles Gute wird genommen. Zum Glück können mehrere Projekte einen Namen teilen ... das ist also, was hier passieren wird.

Ist diese Art des Rostobjektmodells nicht?
Hängt davon ab, wie Sie es betrachten. Ich persönlich ist mir persönlich nicht sehr wichtig - die GUI -Ebene für diese Plattformen ist eine schwierige Voraussetzung für bestimmte Produktklassen, und das Aufgeben von kattiert getesteten Tools für Dinge wie Zugänglichkeit und tiefere Betriebssystemintegration. Trotzdem gibt es interne Anstrengungen, um zu versuchen, die Dinge zu respektieren, die das Modell von Rust, wie die Dinge funktionieren sollten, zu machen.

Sie können sich dies als ähnlich vorstellen wie GTK-Rs. Wenn Sie ein reineres Modell unterstützen oder ausprobieren möchten, schauen Sie sich Druid oder so an. :)

Lizenz

Dual lizenziert unter einer MIT/MPL-2.0-Lizenz. Weitere Informationen finden Sie in den entsprechenden Dateien in diesem Repository. Apple, Appkit, Uikit, Kakao und andere Marken sind Copyright Apple, Inc.