Einstieg in Desktop Apps - Kleinere Tools sollen es werden

[Inxession]

Hallo zusammen,

ich komme immer wieder zu dem Gedanken, eine kleine Desktop App zu "basteln" die mir eine Laser GCode-Datei in spezifische Roboter Sprach-Datei umwandelt.

Ich hab diesen "Slicer" lauffähig in Node-Red.
Ist aber nicht unbedingt die schnellste Lösung und auch nichts was man jedem vorzeigen kann.
Aber es funktioniert.

Im Prinzip macht der "Slicer" nichts anderes als einzelne Zeilen nacheinander zu lesen und verändert auszugeben.

Genau das, soll dann meine Desktop App auch können.

Ich stelle mir allerdings vor, das ich eine Datei über Klicks auswählen kann (Klick - Explorer Fenster auf - Öffnen) und eine Ausgabe Datei (evtl mit Pfad) angeben kann.

Dann typische Kleinigkeit wie starten/stoppen/abbrechen/neustarten und vielleicht eine Anzeige wie weit die Datei schon umgewandelt ist.

Ich möchte es selbst basteln und hab mich nun auf Eelectron eingeschossen.
Da mein Node Red Dings ja bereits in Javascript läuft, ist das denke ich am besten zu adaptieren.

Trotzdem verlier ich den Durchblick.
Vielleicht hat hier jemand bessere Vorschläge und/oder Tipps wie ich das Ganze angehen sollte.

Python ist mir zu "weit weg" von meiner Roboterprogrammierung
Javascript kommt dem am nähesten, von allem was ich bisher gesehen habe.

Gibt es ne gute deutsche Anleitung für Electron, in der auch tiefer gehende Projekte vorgestellt werden? (Also zum Beispiel mit Datei öffnen (egal welche Plattform) und Speichern als..)

Danke für Eure Hilfe.

 

[Autokiller677]

Als jemand, der beruflich Software für Laseranlagen schreibt (u.a. auch Slicer, GUIs etc) - ich würde wenigstens Richtung C# gehen fürs Backend. Du stellst ja selber schon fest, in js sind die Sachen ist nicht gerade schnell.

Frontend mit Electron o.ä., Kommunikation ins Backend (C# / C++) mit gRPC oder irgendwas platzeffizientem. Ist zumindest das, wo aktuell auch die Industrie sich da hinbewegt.

EDIT: Dazu kommt noch, dass Dateisystemzugriff aus dem Browser (oder auch Electron) immer noch so eine Sache ist. Für kleine Dateien geht das klar, die werden dann zum Server hochgeladen und alles läuft, aber wenn du irgendwelche großen G-Code Dateien hast, willst du die eigentlich nicht immer duplizieren. Daher ist das meiste in der Richtung heute eher noch irgendeine "native" GUI (WPF, Qt oder was auch immer).

 

[GrinderFX]

Wieso bitte C#?
Die Sprache ist sowas von absolut....

 

[Autokiller677]

Wieso bitte C#?
Die Sprache ist sowas von absolut....

Weil das unter Windows ein sehr guter Kompromiss zwischen Komfort und Geschwindigkeit ist. Und mit WinForms und WPF die beliebtesten und meist verbreiteten (und entwickelten) GUI Frameworks hat. Und auch insgesamt ein riesiges Ökosystem bietet.

Das ganz harte numerische Backend wie Slicer und co. landen normalerweise in C++, mittlerweile auch manchmal in Rust. Aber für GUI und co. wollen sich das die meisten Firmen eher nicht antun.

Achso, und in der Produktion wie bei mir ein großer Vorteil: Ordentliches Deployment. Python oder Js-Anwendungen auf PCs auf dem Shopfloor auszurollen (häufig ohne Internet-Anbindung) ist meist ein mittelschwerer Albtraum. Mein C# Programm packe in eine .msi und fertig.

 

[DerGoblin2k]

EDIT: Dazu kommt noch, dass Dateisystemzugriff aus dem Browser (oder auch Electron) immer noch so eine Sache ist.

Frage aus Interesse, beim Browser ist klar, aber wieso bei Electron-Apps?

 

[LieberNetterFlo]

Windows und C# (.NET bzw .NET Core oder der gemeinsame Nachfolger) sind schon ein gutes Team ein Visual Studio Community Edition nehmen und anfangen.

Aber python von vorne aus ausschließen würde ich nicht ... normalweise gibt in python Bibliotheken für alles ... vielleicht ja auch für dein Slicen?

 

[Autokiller677]

Frage aus Interesse, beim Browser ist klar, aber wieso bei Electron-Apps?

Da geht es etwas besser als beim Browser, ja, aber so richtig nativ ist es halt auch nicht, so zumindest mein letzter Stand.

Vielleicht hat sich das mittlerweile auch verbessert - wünschenswert wäre es. Auch beim Browser tut sich da mit der (noch ziemlich neuen) File System Access API ja was. In 1-2 Jahren sollte das daher hoffentlich alles kein Thema mehr sein.

 

[KitKat::new()]

Wieso bitte C#?
Die Sprache ist sowas von absolut....

Bitte nicht so viel Inhalt!

 

[DerGoblin2k]

Da geht es etwas besser als beim Browser, ja, aber so richtig nativ ist es halt auch nicht, so zumindest mein letzter Stand.

Vielleicht hat sich das mittlerweile auch verbessert - wünschenswert wäre es. Auch beim Browser tut sich da mit der (noch ziemlich neuen) File System Access API ja was. In 1-2 Jahren sollte das daher hoffentlich alles kein Thema mehr sein.

Die "File System Access API" wird ja bei VSCode verwendet und mir sind da noch keine Nachteile zu anderen Desktop-Apps aufgefallen. Deswegen fragte ich gerade.

 

[Kalsarikännit]

Die Sprache ist sowas von absolut....

...was?

 

[Autokiller677]

Die "File System Access API" wird ja bei VSCode verwendet und mir sind da noch keine Nachteile zu anderen Desktop-Apps aufgefallen. Deswegen fragte ich gerade.

Ein Punkt wäre z.B., dass die API immer noch ein Draft ist (https://wicg.github.io/file-system-access/). Dementsprechend kann man noch mit Breaking Changes rechnen. Wenn man kein Problem damit hat, da regelmäßig zu fixen, kann man das sicher nutzen.

 

[Inxession]

Danke euch einstweilen.

Dann werde ich mir mal Electron.NET anschauen.
Sollte dann C# sein mit HTML Frontend.

Isch gucke!

 

[RenoV]

Sollte dann C# sein mit HTML Frontend.

Da eine wirklich zufriedenstellende Lösung zu finden ist fast unmöglich. Probiere ich auch schon seit einiger Zeit viel herum. CEF ist da die beste Möglichkeit (C# Backend, HTML/JS Frontend). Elektron ist eher... meh.
[ich brauche eine lokale Media-App mit DB... was ich schon alles probiert hab...^^]
Benötigst du zB keine Multimedia-Funktionen (die halt über Browser viel einfacher sind als über WinForms/WPF), dann nimm eine normale Windows App über WPF/WinForms.

 

[Inxession]

... dann nimm eine normale Windows App über WPF/WinForms.

Aber dazu brauch ich das kostenpflichtige Visual Studio, richtig?

Es wird schon wieder unübersichtlich. Das nervt so.

Selbst Electron startet nicht wie im Tutorial beschrieben.

WPF klingt spannend, die ersten Tutorials hegen noch mehr Interesse.
Aber wenn ich jetzt 550 € für Visual Studio berappen soll, dann hat sich das Interesse direkt wieder gelegt.

Ob Visual Studio Code oder VS Community dafür geeignet ist, kann ich nirgends lesen.

 

[LieberNetterFlo]

Aber dazu brauch ich das kostenpflichtige Visual Studio, richtig?

ne, gibt die kostenlose Community Edition, die kann quasi alles was du brauchst

 

[DerGoblin2k]

Aber dazu brauch ich das kostenpflichtige Visual Studio, richtig?

Es wird schon wieder unübersichtlich. Das nervt so.

Selbst Electron startet nicht wie im Tutorial beschrieben.

WPF klingt spannend, die ersten Tutorials hegen noch mehr Interesse.
Aber wenn ich jetzt 550 € für Visual Studio berappen soll, dann hat sich das Interesse direkt wieder gelegt.

Ob Visual Studio Code oder VS Community dafür geeignet ist, kann ich nirgends lesen.

VS Community reicht vollkommen aus.

 

[Autokiller677]

Aber dazu brauch ich das kostenpflichtige Visual Studio, richtig?

Die Community Edition ist kostenlos, außerdem braucht man VS nichtmal zwingend, es ist nur der einfachste Weg.

Der Compiler ist kostenlos und kann einfach in der Kommandozeile aufgerufen werden wenn man es Hardcore mag.

 

[Inxession]

In dieser Hinsicht bin ich weit entfernt von Hardcore
So einfach wie möglich soll es sein.
Aber den Willen mich einzuarbeiten hab ich .... Der Einstieg fällt trotzdem irgendwie schwer, weil man stellenweise mit zu vielen Möglichkeiten konfrontiert wird.

Wundert mich fast schon, das es für native Apps noch keinen WYSIWYG Editor gibt (Node Red und Konsorten mal ausgenommen)

 

[Autokiller677]

Gibt es teilweise. Aber GUIs werden meist schnell relativ komplex, und dann kommt man mit WYSISWYG nicht mehr so weit. Wenn man dynamisch Elemente erstellen will sowieso nicht. Ich bin daher immer schnell wieder dabei gelandet, den GUI Code direkt zu schreiben. Sobald es komplexer wird muss man da eh ran, und dann kann man es auch gleich so machen.

 

[RenoV]

Wundert mich fast schon, das es für native Apps noch keinen WYSIWYG Editor gibt

Im VS gibt es das für WinForms und WPF.
Wenn du grad mit C# & Co anfängst, dann nimm das erst mal (eine normale WinForms-App).
Speziell WinForms ist sehr einfach zu verstehen. Wenn man nur für sich bastelt, ist das ein guter Einstieg.