Plattformübergreifend - Augenauswischerei ...?

[jik]

Kurz zu meiner Vorgeschichte: Ich arbeite seit 1998 mit Delphi. Wir haben damals mit meiner IT-Firma mit Delphi3 begonnen und sind dann bei D5 stehen geblieben, da danach (nach unserer Ansicht damals) die Griffigkeit verlorenging. Bis heute arbeite ich mit D5 und habe nun in Eigenregie seit zehn Jahren ein großes Projekt am Laufen, Patchwork, ein Programm für Schriftsteller, seines Zeichens das umfangreichste Autorenprogramm (viel Eigeninteresse dabei, weil ich selbst schreibe). Immer wieder erhalte ich aber Anfragen, warum es das nicht für 'wenigstens' MacOS gäbe - verständlich, weil sich viele Autoren als Künstler sehen und Künstler gerne Mac nutzen.

Blauäugig (und vielleicht zu draufgängerisch) wie ich nun mal mit Neuem bin, habe ich zuerst mal Lazarus ausprobiert. War positiv überrascht, wie ähnlich es D5 ist, aber ... die wichtigsten Zusatzkomponenten für Patchwork sind die von Developer Express, brauche ich in fast jedem der über 70 Formulare, oft mehrere. Die sind leider nicht auf Lazarus portierbar wegen der zu großen/tiefen Windows-Affinität. Der Ersatz wäre die TVirtualStringTree-Komponente. Anscheinend sehr leistungsfähig, aber vergleichsweise extrem aufwendig/umständlich zu programmieren und vor allem so gut wie nicht dokumentiert - wie das leider oft bei kostenfreien Sachen der Fall ist.

Also hab ich mich doch für D12 entschieden und bin nun da. Denn Delphi 12 ist ja plattformübergreifend und IOS und Android auch noch. Und Embarcadero eine große Firma und es gibt Doku ...
Meine bisherigen Erfahrungen sind - bis auf die Hilfe hier im Forum - eher ernüchternd. Und nun fiel mir siedend heiß in der Nacht ein: Selbst wenn es von DevExpress Grids & Co in neu gibt - sind die überhaupt wenigstens MacOS-fähig??

Vor diesem Post habe ich Artikel hier zu plattformübergreifend gelesen und heftige Zweifel bekommen: 'Nur VCL', 'FMX nicht brauchbar' und weitere abtörnende Erfahrungen.

Nun meine Fragen an euch:
1. Bin ich meiner Blauäugigkeit aufgesessen und sollte mich doch besser in Lazarus hineinfuchsen?
2. Vor allem: Wie erkenne ich (ohne es auszuprobieren), ob Komponenten multi-plattform-fähig sind? Ist offenbar keineswegs selbstverständlich.
3. Wisst ihr, ob überhaupt DevExpress-Grids MacOS-fähig sind ...?
4. Oder würdet ihr bei D5 bleiben, so lange es geht?

Danke für eure Lese- und Antwortszeit. Wäre euch für viele Antworten sehr dankbar, denn es geht um eine große Grundsatzentscheidung, die Mannjahre hinter sich herzieht.

[Uwe Raabe]

Kurz gesagt, wenn du auf DevExpress quasi festgelegt bist, dann musst du bei VCL bleiben. Plattformübergreifend geht bei Delphi mit bordeigenen Mitteln aber nur mit FMX. Selbst das als Zusatzprodukt verfügbare CrossVCL, mit dem VCL-Anwendungen mit Delphi auch für MacOS erstellt werden können, hat die Unterstützung von DevExpress mittlerweile eingestellt.

Natürlich kann man mit Delphi auch für MacOS entwickeln. In der Regel sind aber bestehende VCL-Programme bezüglich des User Interfaces komplett neu aufzubauen. Meistens kommt das einer kompletten Neuentwicklung schon sehr nahe.

[philipp.hofmann]

Wenn man von Anfang an mit FMX mit dem Ziel plattform übergreifend entwickelt, bietet Delphi da einem sehr viel, da bin ich eigentlich recht happy und nutze zusätzlich relativ viele TMS-Komponenten. Eine Portierung eines VCL-Projektes ist aber eine ganz andere Geschichte.

[Phoenix]

Wenn Du wirklich echte zukunftsfähige Cross-Plattform Anwendungen bauen willst, dann bist Du mit allem Nativen auf dem Holzweg. Web-basierte Technologie ist da tatsächlich das einzige das wirklich 100% überall funktioniert.
Wir machen das seit mehr als 10 Jahren extrem erfolgreich. Wir haben schon viele andere Ansätze gesehen und auch Kunden gehabt die das nicht glauben wollten und es anders versucht haben. Davon sind ausnahmslos alle gescheitert.

Oder andersum gesagt, wenn Du etwas für eine Plattform bauen willst, nimm am besten ausschließlich Tools dafür, die auch auf dieser Plattform laufen.
Willst Du für den Mac bauen, nehme Tools die auf dem Mac tun. Willst Du für Mac und Windows bauen, nehme Tools die auf Mac und Windows tun. Willst Du für Mac, Windows, Linux, Android und iOS bauen, nehme Tools die überall dort laufen. Wenn (komplexes) Entwicklungstooling dort läuft, kannst Du davon ausgehen dass auch Deine Anwendung die damit gebaut ist dort tut.

Unser Stack ist Angular fürs Frontend und .NET auf dem Backend, aber alles was JS/TS ist (React, Vue etc.) wird vorne tun und hinten kannst Du gerne auch JS/TS nehmen (Node) wenn Du nix besseres haben willst

[jaenicke]

Zitat von jik:

1. Bin ich meiner Blauäugigkeit aufgesessen und sollte mich doch besser in Lazarus hineinfuchsen?

Lazarus kann durchaus einiges, kommt an Delphi aber bei Weitem nicht heran. Wenn man nur kostenlos möchte und dafür deutlich mehr Aufwand in Kauf nimmt, ist es trotzdem keine schlechte Wahl.

Wenn man aber Kaufkomponenten einbezieht, kommt man mit Delphi meiner Meinung nach deutlich weiter.

Zitat von jik:

2. Vor allem: Wie erkenne ich (ohne es auszuprobieren), ob Komponenten multi-plattform-fähig sind? Ist offenbar keineswegs selbstverständlich.

Das steht dann in der Regel schon deutlich dabei, wenn du im Internet angebotene Komponenten meinst. In Delphi selbst brauchst du nur schauen, was unter FMX zur Verfügung steht.

Zitat von jik:

3. Wisst ihr, ob überhaupt DevExpress-Grids MacOS-fähig sind ...?

Es gibt auch das FMX Data Grid von DevExpress. Das ist plattformunabhängig (Windows, Android, and macOS).

Von TMS gibt es auch größere Sammlungen an plattformunabhängigen Komponenten (TMS FNC UI Pack, ...).

Zitat von jik:

4. Oder würdet ihr bei D5 bleiben, so lange es geht?

Definitiv nicht. Da hat sich so viel getan, unabhängig von Plattformunabhängigkeit, dass das keinen Sinn macht (Unicode, Generics, ...). (Außer, weil der Umstieg zu viel Aufwand wäre natürlich, dann geht es ggf. nicht sofort, aber man sollte dran arbeiten, wenn das Produkt weiterentwickelt wird.)

[Uwe Raabe]

Zitat von jaenicke:

Es gibt auch das FMX Data Grid von DevExpress. Das ist plattformunabhängig (Windows, Android, and macOS).

Ich bin vielleicht nicht ganz auf dem Laufenden, aber hat sich an dem Status wie hier beschrieben mittlerweile was geändert?

[jaenicke]

Da davon nichts bei der Komponente dabei steht, wusste ich davon nichts. Ich habe mich einfach auf diese Webseite verlassen. Ich kenne die DevExpress Komponenten kaum, da ich immer bei denen von TMS war.

[Uwe Raabe]

Okay, dann ist der Blog-Post offenbar immer noch aktuell.

[QuickAndDirty]

Ich weiß nicht wer davon überzeugt ist das FMX nicht brauchbar wäre... Ich finde es besser als die VCL Und habe Apps und Programme für Windows, Android und IOS mit FMX geschrieben. Das geht alles an sich richtig gut.

Lazarus ist auch sehr schön fürs Hobby.

Du wirst kein VCL Projekt mit 70 Formularen auf Android und IOS portieren , es sei denn du hast dich an eine strikte Trennung von Oberfläche und Geschäftlogik gehalten. Dann sollte es kein problem sein die Oberfläche auszutauschen und eine FMX Oberfläche gegen die Geschäftslogik zu binden.
Es steht auch noch zu bedenken, dass du evtl. sowieso neue Formulare designen willst, denn große Auflösungen machen das evtl . notwendig...dann kannst du bei der Gelegenheit gleich zu FMX wechseln.

[himitsu]

Es gibt halt auch ein paar Fallstickte.

Normal hat FMX alle viele System-Komponenten so in etwa nachgebaut.
* nicht nachgebaute Funktionen fehlen dann natürlich
* nativ haben z.B. ScreenReader ein Problem damit, weil für sie diese "Delphi"-Komponenten nicht existieren (gibt es aber teilweise auch eine API zum Nachrüsten, damit "viele" / nicht alle Reader die Infos hintenrum bekommen)
* gibt es ein altes/neues Windows, mit einem anderen Style, dann sieht dein Programm "alt" aus, weil es ja seinen "eigenen" FMX/VCL-Style mitbringt
* ebenso, wenn Windows oder Zusatzprogramme neue Funktionen für eine Komponente nachrüsten, welche die Delphi-Komponente noch nicht kennt
* * z.B. Shortcuts für Smilies/Sonderzeichen, gewisse Eingabeeditoren, Live-Übersetzungen, Sprachsteuerung usw.
* ...

Drum gibt es für einige Komponenten auch die Möglichkeit die native Komponente zu nutzen, welche dann von Delphi über die Form (3D-Zeichenfläche) gelegt wird.