Forum: PC Hard- und Software Cross-Platform Development für Desktop-Anwendung


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Gerhard (Gast)


Lesenswert?

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?

von Le X. (lex_91)


Lesenswert?

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.

von Εrnst B. (ernst)


Lesenswert?

+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".

von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

Ich verwende XOJO.

Für Windows, MacOS/iOS, Linux X86 und ARM (Raspi).
Kennt kaum jemand ... hier mal gucken:

https://www.xojo.com

von DenkenMachtSpaß (Gast)


Lesenswert?

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

von Stefan F. (Gast)


Lesenswert?

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.

von Εrnst B. (ernst)


Lesenswert?

Stefan F. schrieb:
> Die Bediensoftware für einen Programmieradapter würde ich aber auf gar
> keinen Fall als Web-Anwendung implementieren.

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.

: Bearbeitet durch User
von Gerhard (Gast)


Lesenswert?

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.

Le X. schrieb:
> Ich persönlich halte nichts davon alles in den Browser zu verlagern und
> bevorzuge native Programme.

Genau. Das wollen wir genauso machen.

Frank E. schrieb:
> Ich verwende XOJO.

Schaue ich mir an, danke.

DenkenMachtSpaß schrieb:
> Was aus Deinem Posting nicht ganz klar wird: Quelltext-portabel oder
> binärportabel?

Quelltextportabel.

> Für Quelltextportabilität wäre auch noch QT zu nennen. Von der
> Funktionalität ziemlich vollständig.

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.

Stefan F. schrieb:
> 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.

Ja, das meinte ich. Falsch ausgedrückt. Die Anwendung soll quasi 
identisch funktionieren, aber optisch im Stil des jeweiligen Systems.

Stefan F. schrieb:
> 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.

Mobile Geräte kommen bei uns nicht vor, alle Clients sind auf dem 
Desktop. Ist auch nicht absehbar, dass sich das ändert.

von Stefan F. (Gast)


Lesenswert?

Εrnst B. schrieb:
> Sind allerdings noch teilweise experimental

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.

von Stefan F. (Gast)


Lesenswert?

Gerhard schrieb:
> 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.

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.

von Le X. (lex_91)


Lesenswert?

Gerhard schrieb:
> 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.

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.

von Rolf M. (rmagnus)


Lesenswert?

Stefan F. schrieb:
> Ich mag Qt, allerdings mit Widgets im nativem Look, also genau das
> Gegenteil von mit identischem Look&Feel.

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.

> Ich finde, dass die meisten Anwendungen von dem einheitlichen Look&Feel
> profitieren, dass das jeweilige OS vorgibt.

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.

> Web basierte Anwendungen profitieren von der Fähigkeit des Browsers, den
> Seiteninhalt optimal an die Geometrie des Bildschirms anzupassen

Gefühlt macht das aber keine.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.