Oberflächen mit Rust: Tauri, Slint, egui oder iced?
Vier Ansätze mit unterschiedlichen Zielen und keiner davon der offensichtliche Standard. Die Entscheidung fällt an Kriterien, die auch in drei Jahren noch gelten.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Rust-Oberflächenlandschaft ist in Bewegung, und das gehört in die Planung
Wer nach einer Oberflächenbibliothek für Rust sucht, findet Vergleichslisten, aber keinen Konsens. Das ist keine Lücke in der Recherche, sondern die Lage: Es gibt keine Bibliothek, auf die sich das Ökosystem geeinigt hätte, mehrere der bekannten Kandidaten stehen weiterhin in der Null-Reihe ihrer Versionsnummern, und das Verzeichnis, das diesen Bereich pflegt, führt sie bis heute nebeneinander auf, ohne eine davon als ausgereifte Standardlösung zu bezeichnen.
Der übliche Fehler ist trotzdem nicht, die falsche Bibliothek zu nehmen. Der übliche Fehler ist, entlang der falschen Kriterien zu entscheiden. Gewählt wird nach dem Eindruck der Beispielanwendung oder nach der Zahl der Sterne im Verzeichnis, und ein halbes Jahr später stellt sich heraus, dass die Anwendung barrierefrei sein muss, dass sie zusätzlich auf einem Bedienpanel laufen soll oder dass die Lizenz eine Abgabe je ausgeliefertem Gerät vorsieht.
Teuer wird das, weil eine Oberfläche schlecht austauschbar ist. Der Rechenkern einer Anwendung überlebt einen Wechsel, die Oberfläche wird neu geschrieben. Deshalb lohnt es sich, die drei Fragen vorzuziehen, die sich später nicht mehr ändern lassen: Wer muss die Anwendung bedienen können, auf welchen Geräten läuft sie, und unter welchen Bedingungen dürft ihr sie ausliefern.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die drei Ansätze nebeneinander
Zusammengefasst zu drei Bauweisen, weil egui und iced dieselbe Grundentscheidung teilen: Rust zeichnet die Oberfläche selbst. Die Unterschiede zwischen den beiden stehen weiter unten im Text.
Tauri
eine Weboberfläche in einem Systemfenster, während Rust im Hintergrund die Arbeit macht
Slint
eine eigene Beschreibungssprache für die Oberfläche, übersetzt und lauffähig vom Desktop bis auf ein Gerätedisplay
egui und iced
Rust zeichnet die Oberfläche selbst, bei egui unmittelbar je Bild, bei iced über einen Nachrichtenkreislauf
| Entscheidungsfrage | Tauri | Slint | egui und iced |
|---|---|---|---|
| Was muss euer Team dafür schon können? | Kommt darauf an HTML, CSS und ein Frontend-Framework reichen für die gesamte Oberfläche, Rust braucht ihr nur für die Befehle im Hintergrund. Dafür betreibt ihr als einzige der drei Varianten zwei Werkzeugketten nebeneinander, Cargo und einen Node-Build, und jede Änderung an der Grenze zwischen beiden Seiten fasst zwei Sprachen an. | Kommt darauf an Die Oberfläche wird in einer eigenen, kleinen Sprache beschrieben, die niemand vorher kennt. Sie ist schnell gelernt, ist aber zusätzliches Wissen, das im Team verankert werden muss. | Kommt darauf an Alles läuft in Rust. Bei egui steht die erste Oberfläche in Minuten, bei iced muss zuerst der Nachrichtenkreislauf aus Zustand, Nachricht und Ansicht sitzen. |
| Wo läuft das Ergebnis am Ende? | Stärke Auf allen großen Rechnerplattformen, seit Version 2 zusätzlich auf iOS und Android. Was nicht geht, ist ein Display ohne Betriebssystem, denn es braucht die Systemansicht. | Stärke Vom Desktop über eingebettetes Linux bis hinunter auf Mikrocontroller, dort mit einem reinen Softwarezeichner ohne Grafikbeschleunigung. Diese Spannweite hat unter den vieren sonst keiner. | Kommt darauf an Rechnerplattformen sind der Zielbereich, egui läuft zusätzlich über WebAssembly im Browser. Auf Geräten mit knapper Grafikausstattung wird es schwierig, weil beide eine Zeichenschicht voraussetzen. |
| Sieht die Anwendung auf allen Plattformen gleich aus? | Schwäche Nein, und das ist der am häufigsten unterschätzte Punkt. Unter Windows, macOS und Linux zeichnet jeweils eine andere Systemansicht, sodass dieselbe Formatierung abweichen kann. Getestet werden muss auf allen drei. | Stärke Ja, weil die Bibliothek selbst zeichnet. Der Preis ist derselbe wie bei den anderen selbstzeichnenden Ansätzen: Es ist nicht das gewohnte Erscheinungsbild der jeweiligen Plattform. | Stärke Ja, jedes Bedienelement wird selbst gezeichnet und sieht überall identisch aus. Wer die plattformüblichen Bedienelemente erwartet, bekommt sie hier nicht. |
| Wie gut lässt sich die Anwendung mit Hilfstechnik bedienen? | Stärke Die Systemansicht meldet dem Betriebssystem einen Dokumentenbaum, sodass Vorleseprogramme und Tastaturbedienung funktionieren, sofern euer HTML sauber ausgezeichnet ist. In Projekten mit Anforderungen an Barrierefreiheit ist das das stärkste Argument. | Kommt darauf an Es gibt Unterstützung dafür, aber die Elemente müssen bewusst ausgezeichnet werden. Das ist Arbeit, die eingeplant und geprüft gehört, statt sie als gegeben anzunehmen. | Schwäche Eine selbst gezeichnete Oberfläche meldet dem Betriebssystem von sich aus gar nichts, weil es keinen Bedienbaum gibt, den es melden könnte. egui bindet dafür eine eigene Zwischenschicht ein, das muss aber ausdrücklich aufgebaut und geprüft werden. |
| Was ist bei Paketgröße und Start zu erwarten? | Stärke Weil keine Browsermaschine mitgeliefert wird, nennt die Dokumentation für eine minimale Anwendung weniger als 600 Kilobyte. Der Haken liegt beim Ausliefern unter Linux, wo die Systemansicht als Abhängigkeit vorhanden sein muss. | Stärke Die Oberfläche wird vorab übersetzt, die Laufzeit ist klein genug für Mikrocontroller. Genau daran erkennt man, worauf der Aufbau ausgelegt ist. | Kommt darauf an Es entsteht eine in sich geschlossene Binärdatei ohne fremde Abhängigkeiten. Dafür kommt eine Grafikschicht mit, die auf dem Zielsystem einen brauchbaren Treiber oder einen Rückfallpfad braucht. |
| Wie sieht die Lizenzlage aus? | Stärke Freizügig lizenziert, ohne Abgabe je Gerät und ohne Rückfrage bei der Rechtsabteilung. Für die meisten Häuser der unkomplizierteste der drei Fälle. | Kommt darauf an Mehrgleisig: GPLv3 für offene Projekte, gebührenfreie Nutzung für proprietäre Anwendungen außerhalb eingebetteter Systeme, dazu kostenpflichtige Stufen. Für kommerzielle eingebettete Geräte fällt eine einmalige Abgabe ab einem US-Dollar je Gerät an. | Stärke Beide stehen unter freizügigen Lizenzen ohne Abgabe je Gerät. Das ist der einfachste Fall, verlagert die Frage aber auf die Wartung, weil beide von kleinen Teams getragen werden. |
Was muss euer Team dafür schon können?
HTML, CSS und ein Frontend-Framework reichen für die gesamte Oberfläche, Rust braucht ihr nur für die Befehle im Hintergrund. Dafür betreibt ihr als einzige der drei Varianten zwei Werkzeugketten nebeneinander, Cargo und einen Node-Build, und jede Änderung an der Grenze zwischen beiden Seiten fasst zwei Sprachen an.
Die Oberfläche wird in einer eigenen, kleinen Sprache beschrieben, die niemand vorher kennt. Sie ist schnell gelernt, ist aber zusätzliches Wissen, das im Team verankert werden muss.
Alles läuft in Rust. Bei egui steht die erste Oberfläche in Minuten, bei iced muss zuerst der Nachrichtenkreislauf aus Zustand, Nachricht und Ansicht sitzen.
Wo läuft das Ergebnis am Ende?
Auf allen großen Rechnerplattformen, seit Version 2 zusätzlich auf iOS und Android. Was nicht geht, ist ein Display ohne Betriebssystem, denn es braucht die Systemansicht.
Vom Desktop über eingebettetes Linux bis hinunter auf Mikrocontroller, dort mit einem reinen Softwarezeichner ohne Grafikbeschleunigung. Diese Spannweite hat unter den vieren sonst keiner.
Rechnerplattformen sind der Zielbereich, egui läuft zusätzlich über WebAssembly im Browser. Auf Geräten mit knapper Grafikausstattung wird es schwierig, weil beide eine Zeichenschicht voraussetzen.
Sieht die Anwendung auf allen Plattformen gleich aus?
Nein, und das ist der am häufigsten unterschätzte Punkt. Unter Windows, macOS und Linux zeichnet jeweils eine andere Systemansicht, sodass dieselbe Formatierung abweichen kann. Getestet werden muss auf allen drei.
Ja, weil die Bibliothek selbst zeichnet. Der Preis ist derselbe wie bei den anderen selbstzeichnenden Ansätzen: Es ist nicht das gewohnte Erscheinungsbild der jeweiligen Plattform.
Ja, jedes Bedienelement wird selbst gezeichnet und sieht überall identisch aus. Wer die plattformüblichen Bedienelemente erwartet, bekommt sie hier nicht.
Wie gut lässt sich die Anwendung mit Hilfstechnik bedienen?
Die Systemansicht meldet dem Betriebssystem einen Dokumentenbaum, sodass Vorleseprogramme und Tastaturbedienung funktionieren, sofern euer HTML sauber ausgezeichnet ist. In Projekten mit Anforderungen an Barrierefreiheit ist das das stärkste Argument.
Es gibt Unterstützung dafür, aber die Elemente müssen bewusst ausgezeichnet werden. Das ist Arbeit, die eingeplant und geprüft gehört, statt sie als gegeben anzunehmen.
Eine selbst gezeichnete Oberfläche meldet dem Betriebssystem von sich aus gar nichts, weil es keinen Bedienbaum gibt, den es melden könnte. egui bindet dafür eine eigene Zwischenschicht ein, das muss aber ausdrücklich aufgebaut und geprüft werden.
Was ist bei Paketgröße und Start zu erwarten?
Weil keine Browsermaschine mitgeliefert wird, nennt die Dokumentation für eine minimale Anwendung weniger als 600 Kilobyte. Der Haken liegt beim Ausliefern unter Linux, wo die Systemansicht als Abhängigkeit vorhanden sein muss.
Die Oberfläche wird vorab übersetzt, die Laufzeit ist klein genug für Mikrocontroller. Genau daran erkennt man, worauf der Aufbau ausgelegt ist.
Es entsteht eine in sich geschlossene Binärdatei ohne fremde Abhängigkeiten. Dafür kommt eine Grafikschicht mit, die auf dem Zielsystem einen brauchbaren Treiber oder einen Rückfallpfad braucht.
Wie sieht die Lizenzlage aus?
Freizügig lizenziert, ohne Abgabe je Gerät und ohne Rückfrage bei der Rechtsabteilung. Für die meisten Häuser der unkomplizierteste der drei Fälle.
Mehrgleisig: GPLv3 für offene Projekte, gebührenfreie Nutzung für proprietäre Anwendungen außerhalb eingebetteter Systeme, dazu kostenpflichtige Stufen. Für kommerzielle eingebettete Geräte fällt eine einmalige Abgabe ab einem US-Dollar je Gerät an.
Beide stehen unter freizügigen Lizenzen ohne Abgabe je Gerät. Das ist der einfachste Fall, verlagert die Frage aber auf die Wartung, weil beide von kleinen Teams getragen werden.
Was passt wann
- Wenn Weboberflächen die vorhandene Stärke im Team sind und die Anwendung mit Hilfstechnik bedienbar sein muss
- ist Tauri die Wahl mit dem geringsten Risiko, weil die Systemansicht den Bedienbaum bereits meldet.
- Wenn dieselbe Oberfläche auf dem Rechner und auf einem Gerätedisplay laufen soll
- führt an Slint kaum ein Weg vorbei, und die Lizenzfrage gehört dann an den Anfang des Projekts und nicht vor die Auslieferung.
- Wenn es um ein internes Werkzeug geht, das schnell fertig sein und danach wenig kosten soll
- ist egui die kürzeste Strecke, und iced die bessere Grundlage, sobald daraus eine Anwendung mit mehreren Ansichten und langem Leben wird.
Sechs Fragen, die die Auswahl in den meisten Projekten entscheiden
- 01 Kann euer Team Weboberflächen, oder ist alles in Rust die kürzere Strecke?
- 02 Muss die Anwendung mit Hilfstechnik wie einem Vorleseprogramm bedienbar sein?
- 03 Läuft sie nur auf Rechnern, oder auch auf Mobilgeräten und Bedienpanels?
- 04 Darf das Aussehen je Plattform abweichen, oder muss es überall gleich sein?
- 05 Gibt es eine Abgabe je ausgeliefertem Gerät, und wer gibt die frei?
- 06 Wer pflegt die Oberfläche in fünf Jahren, wenn sich das Feld verschoben hat?
Danach begründest du die Auswahl, statt sie zu verteidigen
Die vier Ansätze lösen unterschiedliche Aufgaben, und für die meisten Projekte schließen zwei bis drei Kriterien den größten Teil des Feldes schon aus. Was übrig bleibt, ist dann keine Geschmacksfrage mehr.
Die vier Ansätze auseinanderhalten
Du weißt, ob eine Bibliothek eine Systemansicht mit Weboberfläche steuert, die Oberfläche aus einer eigenen Sprache übersetzt oder sie selbst Bild für Bild zeichnet, und welche Folgen das jeweils hat.
Barrierefreiheit früh klären
Du erkennst, warum eine selbst gezeichnete Oberfläche dem Betriebssystem von sich aus keinen Bedienbaum meldet, und ziehst diese Frage vor die Auswahl statt in die Abnahme.
Zielplattformen vollständig auflisten
Du prüfst nicht nur Windows, macOS und Linux, sondern auch mobile Ziele und Gerätedisplays, weil genau daran mehrere Kandidaten ausscheiden.
Lizenzen vor dem Prototyp lesen
Du kennst den Unterschied zwischen einer freizügigen Lizenz und einem Modell mit Abgabe je ausgeliefertem Gerät und holst dazu die Freigabe ein, bevor Code entsteht.
Paketgröße und Start einschätzen
Du weißt, wo die Größe herkommt, und kennst die Kehrseite einer mitgenutzten Systemansicht: Die Darstellungsmaschine unterscheidet sich je Plattform.
Auf Bewegung im Feld einstellen
Du planst damit, dass sich die Lage in zwei Jahren anders darstellen kann, und hältst die Fachlogik von der Oberfläche getrennt, damit ein Wechsel nicht das ganze Projekt trifft.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Erst die ehrliche Lage, dann die Auswahl
Es gibt für Rust kein Gegenstück zu dem, was Qt für C++ oder WPF für .NET ist. Mehrere Ansätze stehen nebeneinander, sie verfolgen unterschiedliche Ziele, und ein Teil davon trägt weiterhin Versionsnummern unterhalb von eins, was ausdrücklich bedeutet, dass sich die Schnittstelle noch ändern darf. Das Verzeichnis, das diesen Bereich seit Jahren dokumentiert, fasst die Lage in einem Satz zusammen, der als Untertitel über der Liste steht: Die Wurzeln reichen noch nicht tief, aber die Saat ist ausgebracht.
Daraus folgt keine Empfehlung, sondern eine Arbeitsweise. Halte die Fachlogik konsequent aus der Oberfläche heraus, in eigenen Crates mit eigenen Tests, die nichts über Fenster und Bedienelemente wissen. Dann ist ein Wechsel der Oberfläche in fünf Jahren ein abgegrenztes Projekt und nicht das Ende der Anwendung. Diese Trennung lohnt sich in jeder Sprache, hier ist sie keine Kür.
Zwei Wege fehlen in Vergleichslisten regelmäßig. Der eine ist Dioxus: ein an React angelehnter Aufbau aus Komponenten, der Desktop, Web und Mobilgeräte aus einer Codebasis bedient und auf dem Desktop dieselbe Systemansicht nutzt wie Tauri, den Zustand aber in Rust hält statt in JavaScript. Es steht wie egui und iced noch unterhalb von Version eins. Der andere sind Anbindungen an die etablierten Werkzeugkästen: Für GTK gibt es gepflegte Rust-Anbindungen, für Qt eine Brücke über die C++-Seite. Wenn ihr eine Anwendung baut, die sich in eine bestehende Desktopumgebung einfügen soll, ist das oft die sachlich richtige Antwort, auch wenn sie weniger nach Rust aussieht.
Tauri: Weboberfläche im Systemfenster
Tauri liefert keine Browsermaschine mit, sondern benutzt die, die auf dem Zielsystem ohnehin vorhanden ist. Eure Oberfläche ist eine Webanwendung mit dem Framework eurer Wahl, der Rust-Teil läuft daneben als eigener Prozessteil und stellt Befehle bereit, die die Oberfläche aufruft. Alles, was Dateien, Netzwerk, Datenbanken oder rechenintensive Arbeit betrifft, liegt auf der Rust-Seite, und die Grenze dazwischen ist eine schmale, klar benannte Schnittstelle.
Der Preis für die mitgenutzte Systemansicht ist die Uneinheitlichkeit. Unter Windows, macOS und Linux zeichnet jeweils eine andere Maschine, mit unterschiedlichem Stand bei neueren Formatierungsmöglichkeiten. Eine Oberfläche, die im Entwicklungsbrowser gut aussieht, kann auf einer der drei Plattformen anders umbrechen, und das merkt ihr nur, wenn ihr dort tatsächlich testet. Wer aus der Electron-Welt kommt und daran gewöhnt ist, überall dieselbe Maschine zu haben, unterschätzt diesen Punkt regelmäßig.
Zwei Dinge sprechen dafür, die selten genannt werden. Erstens das Rechtemodell: In Tauri wird ausdrücklich festgelegt, welche Befehle die Oberfläche überhaupt aufrufen darf, statt dass die Weboberfläche unbeschränkten Zugriff auf das System bekommt. Zweitens die Barrierefreiheit, die schlicht mitkommt, weil die Systemansicht dem Betriebssystem einen Dokumentenbaum meldet. In Projekten, in denen Vorleseprogramme und vollständige Tastaturbedienung gefordert sind, ist das ein Argument, das die anderen Ansätze erst mit Aufwand einholen müssen.
Slint: eine eigene Sprache für die Oberfläche
Bei Slint beschreibst du die Oberfläche in einer eigenen, deklarativen Sprache in .slint-Dateien: Elemente, Eigenschaften, Bindungen, Zustände. Diese Beschreibung wird vorab übersetzt und nicht zur Laufzeit ausgewertet, was der Grund dafür ist, dass dieselbe Oberfläche auf einem Mikrocontroller läuft. Für das Zeichnen gibt es mehrere Wege, von der beschleunigten Darstellung auf dem Rechner bis zu einem reinen Softwarezeichner für Geräte ohne Grafikeinheit.
Die Anbindung gibt es nicht nur für Rust, sondern auch für C++, JavaScript und Python. Für Häuser mit einer gewachsenen C++-Codebasis in der Gerätewelt ist das der eigentliche Reiz: Die Oberfläche wird einmal beschrieben und lässt sich an das anbinden, was schon da ist. Anders als bei den meisten anderen Kandidaten liegt die Versionsnummer außerdem in der Eins-Reihe, die Schnittstelle ist also erklärtermaßen stabil.
Das Lizenzmodell gehört an den Anfang jeder Slint-Entscheidung und nicht in die Abnahme. Es ist mehrgleisig: GPLv3 für offene Projekte, eine gebührenfreie Nutzung für proprietäre Anwendungen außerhalb eingebetteter Systeme, dazu kostenpflichtige Stufen mit Staffelungen für kleine Unternehmen. Für kommerzielle eingebettete Geräte fällt eine einmalige Abgabe an, laut Anbieter ab einem US-Dollar je Gerät mit Mengenrabatten. Bei einer Stückzahl im sechsstelligen Bereich ist das eine Position im Produktkalkül, über die nicht das Entwicklungsteam entscheidet.
egui und iced: Rust zeichnet selbst
egui arbeitet unmittelbar: Es gibt keinen dauerhaften Baum aus Bedienelementen, sondern der Code beschreibt in jedem Bild neu, was zu sehen ist. Eine Schaltfläche ist ein Aufruf, der zurückgibt, ob sie in diesem Bild gedrückt wurde. Das macht die Sache verblüffend kurz und erklärt, warum egui die erste Wahl für Werkzeuge ist, die Entwicklerinnen und Entwickler für sich selbst bauen, für Debugansichten, Parametereinstellungen und Messwerkzeuge. Die Kehrseite ist ebenso deutlich: aufwendige Layouts sind mühsam, und der Aufbau zeichnet grundsätzlich fortlaufend neu, was auf einem Notebook im Akkubetrieb auffällt, sofern man es nicht ausdrücklich auf Zeichnen bei Bedarf umstellt.
iced folgt der anderen Schule: Es gibt einen Zustand, es gibt Nachrichten, es gibt eine Funktion, die aus dem Zustand die Ansicht baut, und eine, die auf Nachrichten hin den Zustand ändert. Wer aus der Frontend-Welt kommt, erkennt das Muster sofort. Der Gewinn zeigt sich bei größeren Anwendungen, weil der Zustand an genau einer Stelle liegt und Änderungen nachvollziehbar bleiben. Der stärkste reale Hinweis auf die Tragfähigkeit ist die Desktopumgebung COSMIC von System76, deren Oberfläche auf dieser Grundlage aufgebaut ist.
Bei beiden gilt derselbe Vorbehalt: Die Versionsnummern liegen unterhalb von eins, Aktualisierungen bringen von Zeit zu Zeit Anpassungen mit, und die Entwicklung liegt bei kleinen Teams. Für ein internes Werkzeug ist das ohne Belang. Für ein Produkt mit zehn Jahren Pflegezusage gehört diese Aussage in dieselbe Tabelle wie die technischen Kriterien.
Die Kriterien, die eure Entscheidung überdauern
Barrierefreiheit steht an erster Stelle, weil sie sich nachträglich am schlechtesten einbauen lässt. Eine selbst gezeichnete Oberfläche besteht aus Pixeln, nicht aus Bedienelementen, und ein Vorleseprogramm bekommt vom Betriebssystem schlicht nichts geliefert, solange nicht eigens eine Beschreibung des Bedienbaums nebenherläuft. Genau dafür gibt es Zwischenschichten, die egui einbindet, aber es bleibt Arbeit, die geplant und geprüft gehört. Wenn eure Anwendung in einer Behörde läuft oder von Menschen mit Einschränkungen bedient werden muss, schließt dieses Kriterium das Feld schneller ein als jedes andere.
Die Zielplattformen führt ihr vollständig auf, bevor ihr vergleicht, und zwar einschließlich der Fälle, die jemand nebenbei erwähnt hat. Ein Bedienpanel an einer Maschine, ein Tablet im Außendienst oder ein Messgerät mit kleinem Display verschieben die Auswahl sofort, weil die Systemansicht dort nicht zur Verfügung steht und eine Grafikschicht nicht vorausgesetzt werden kann.
Und die Lizenz klärt ihr, bevor der Prototyp entsteht, nicht danach. Eine gebührenfreie Nutzung für den Desktop bedeutet nicht dasselbe wie eine gebührenfreie Nutzung auf einem ausgelieferten Gerät, und eine Abgabe je Gerät ist eine Größe, die in die Produktkalkulation gehört. Diese eine Stunde am Anfang ersetzt eine unangenehme Runde kurz vor der Auslieferung.
Dazu passende Kurse
Weil sich die Unterschiede zwischen den Ansätzen erst beim Bauen zeigen und nicht in der Übersicht, lohnen sich Rust-Kurse für Desktop-Anwendungen .
Wer die Oberfläche in HTML und CSS baut und Rust nur im Hintergrund einsetzt, findet für beide Seiten passende Einstiege in das Programmierangebot von cmt im Überblick .
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Sehr angenehmes, gut vorbereitetes Seminar, kann ich nur empfehlen.
Häufige Fragen
Gibt es in Rust eine Standardlösung für Oberflächen?
Ist Tauri einfach ein leichteres Electron?
Kann ich mit egui oder iced eine Anwendung bauen, die aussieht wie das Betriebssystem?
Was kostet Slint für ein kommerzielles Gerät?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Rust-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Eine Oberfläche, die auch den nächsten Wechsel im Feld übersteht
Wie du Fachlogik und Darstellung so trennst, dass die Auswahl später revidierbar bleibt, baust du bei cmt an einer echten Anwendung auf.