|
Anzeige
|
Cross-Platform Development für Desktop-Anwendung
Gast
#7347205
Moin, was ist denn heutzutage eine sinnvolle Basis für eine Desktop-Anwendung, die gleichermaßen auf Linux, Mac und Windows funktioniert, am besten mit identischem Look&Feel? Es geht um einen Client für eine Datenbankanwendung. Es geht um die Abwicklung von Reparaturaufträgen. Ist WxWidgets noch aktuell? Oder Qt? Wobei ich da von abschreckenden Lizenzmodellen gehört habe... Oder gibt es noch andere Optionen? Der Tenor bei Plattformunabhängigkeit geht mittlerweile in Richtung Web-Entwicklung. Ich persönlich halte nichts davon alles in den Browser zu verlagern und bevorzuge native Programme. Aber gerade in deinem Fall, einen Client / Frontend für eine Datenbank, dürfte irgendwas webbasiertes tatsächlich das Mittel der Wahl sein. +1 für die Web-Lösung. Die kannst du immer noch zur PWA erweitern, dann lässt sich die auch mit Startmenu-Eintrag/Desktop-Icon installieren (dasselbe auch auf Tablets und Mobiltelefonen), und schaut dann auch nicht mehr ganz so offensichtlich nach Webbrowser aus. Oder statt PWA den weg über "electron" gehen, (https://www.electronjs.org/), und deine HTML/JS-Applikation einfach fest mit einem Webbrowser koppeln, und daraus ein Installationspacket bauen... Prominentes Beispiel wär z.B. Visual Studio Code. Das hält auch kaum jemand für eine "Web-App". Ich verwende XOJO. Für Windows, MacOS/iOS, Linux X86 und ARM (Raspi). Kennt kaum jemand ... hier mal gucken:
Gast
#7347667
Hallo Gerhard, Java mit javaFX oder direkt Web-Anwendung. GUIs wie wxWidgets wirken halt altbacken. JavaFX ist da optisch schon deutlich moderner und nicht so "aus der Zeit gefallen". Was aus Deinem Posting nicht ganz klar wird: Quelltext-portabel oder binärportabel? Für Quelltextportabilität wäre auch noch QT zu nennen. Von der Funktionalität ziemlich vollständig. Gruß Marcus
Gast
#7347688
Ich mag Qt, allerdings mit Widgets im nativem Look, also genau das Gegenteil von mit identischem Look&Feel. Ich finde, dass die meisten Anwendungen von dem einheitlichen Look&Feel profitieren, dass das jeweilige OS vorgibt. Web basierte Anwendungen profitieren von der Fähigkeit des Browsers, den Seiteninhalt optimal an die Geometrie des Bildschirms anzupassen und mittels CSS formatieren zu können. Bei stark dynamischem Inhalt, den man meist bei Geschäftsanwendungen hat, kommt man so zügig voran. Die Bediensoftware für einen Programmieradapter würde ich aber auf gar keinen Fall als Web-Anwendung implementieren. Da sind Formulare mit Widgets einfacher. Bei Desktop Anwendungen für Maus+Tasteur mag ich klassische Menüs, doch die taugen eher nicht für Geräte mit Touch. Google hatte sich mal eine "Action Bar" beschrieben, die die Bedürfnisse beider Gerätetypen abdecken sollte. Mir hat es gefallen, deswegen hatte ich das mal so ähnlich in Qt implementiert: http://stefanfrings.de/actionbar/index.html Das kann kein Menü ersetzen, aber für manche Anwendungen taugt es als Kompromiss.
ist aber auch kein Problem. VS-Code mit den diversen AVR, Arduino, Plattformio, ... -Plugins macht genau das. Allerdings über den Umweg avrdude&co. Und auch ohne Electron, d.H. echte Webseite im Browser, kann man per Javascript auf Serielle Ports, Bluetooth und USB-Geräte zugreifen. https://developer.mozilla.org/en-US/docs/Web/API/Web_Serial_API https://developer.mozilla.org/en-US/docs/Web/API/WebUSB_API https://developer.mozilla.org/en-US/docs/Web/API/WebHID_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API Sind allerdings noch teilweise experimental und nicht per default aktiv.
Gast
#7347716
Vielen Dank für die vielen Hinweise. Eine Browser-basierte Oberfläche kommt für uns nicht in Frage. Höchstens als Zusatzfeature, um bestimmte (hauptsächlich lesende) Zugriffe auch vom Browser aus machen zu können. Wir leiden ziemlich unter diversen aufgeblasenen Software-Monstren, die nur in einem bestimmten Browser richtig funktionieren, einen ungeheuren Ressourcen-Verbrauch haben und trotzdem nicht schnell genug laufen, so dass man als Anwender ständig genervt ist. Und die Anpassung an die Bildschirmgröße mittels CSS funktioniert auch nur theoretisch. In der Praxis muss man dann für manche Bedienelemente doch scrollen. Und häufig friert einfach alles ein und der Prozessor geht auf 100% Last. Nach einem Browser-Neustart ist dann die Frage, welche Aktion hat zuletzt noch funktioniert und welche nicht.
Genau. Das wollen wir genauso machen.
Schaue ich mir an, danke.
Quelltextportabel.
Hatte ich schon auf dem Schirm, aber über die Lizenzmodelle habe ich schlimme Sachen gehört. Es scheint nur noch Abomodelle zu geben, die überhaupt keinen Sinn machen, wenn man die Software verkaufen möchte.
Ja, das meinte ich. Falsch ausgedrückt. Die Anwendung soll quasi identisch funktionieren, aber optisch im Stil des jeweiligen Systems.
Mobile Geräte kommen bei uns nicht vor, alle Clients sind auf dem Desktop. Ist auch nicht absehbar, dass sich das ändert.
Gast
#7347719
Leider. Auf Bluetooth und UDP bin ich richtig scharf. Dann würde ich die Bedien-Oberflächen vieler Geräte in HTML/Javascript implementieren. Die ESP Module sind dafür ideal.
Gast
#7347722
Die meisten Teile von Qt wurden unter der LGPL veröffentlicht. Diese kannst du ohne Lizenzgebühren verwenden. Nur wenige spezielle Teile erfordern die kostenpflichtige Lizenz. https://de.wikipedia.org/wiki/GNU_Lesser_General_Public_License Gehe mal auf https://www.qt.io/product/features?hsLang=en und filtere dann am linken Rand nach der LGPL Lizenz. Scrolle dan runter zu "Framework Add-Ons", dort siehst du, was dir als Open-Source User entgeht. Es ist nicht viel. Die meisten Sachen kann man durch andere Bibliotheken abdecken, wenn es sein muss. Qt hat versprochen, dass die LGPL Komponenten für immer LGPL bleiben. Bisher haben sie sich auch daran gehalten. Insofern ist das durchaus Zukunft-sicher.
Naja, der Einwand ist schon etwas seltsam. Wenn ihr die SW eh selber neu erstellt habt ihr es doch in der Hand ob eure Lösung ein Software-Monster wird und welchen Ressourcenverbrauch sie hat. Ich hab hier einige Beispiele wo die Umsetzung im Browser gut ist und teilweise sogar flüssiger als die nativen Clients die wir früher hatten (z.B. Jira, gitlab oder bitbucket, die Proxmox-GUI uvm. Auf der anderen Seite gibt es aber auch Anwendungen wo die Browserintegration gescheitert ist. Word und Excel sind im Browser praktisch unbenutzbar.
Das sehe ich genau so. Wobei es bei Qt ja vor allem eine Sache der Konfiguration ist, ob es überall gleich aussieht oder sich an den jeweiligen Desktop anpasst.
Ja, das ist auch was, was mich an Web-Anwendungen stört. Die tun das in der Regel nicht. Wobei man unter Windows ja eh kaum noch von einem einheitlichen Look&Feel sprechen kann. Da macht ja gefühlt jedes Programm inzwischen sein eigenes Ding, auch die von Microsoft selbst.
Gefühlt macht das aber keine. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
