Sind wir veraltet?

[Rollo62]

Zitat von Codehunter:

Ja eben! Mal über den Microsoft-Tellerrand hinaus gedacht: Stell dir mal vor, deine ganzen Spezialprogramme laufen gleichermaßen unter Linux, Mac und Windows, sehen gleich aus und verhalten sich gleich. Dann kommst du irgendwann an den Punkt wo das Betriebssystem egal wird.

Deshalb habe ich mich zu 100*% auf FMX eingelassen, wohl wissend das natürlich Javascript oder WebAssembly Lösungen noch plattformunabhängiger sind.
Deren Problem ist aber, weil browserbasierend, dass auch nicht alle Betriebssystem-Spezialitäten insbesondere Hardware, abgebildet werden können.
Ich hatte mir zuletzt mal MAUI angesehen, auch da gibt es für mich noch zu viele Lücken.

Die Lösung ist dann eben rigoros funktional abzuspecken und dem Kunden mal hier und das ein "Geht nicht" anzubieten

[Codehunter]

FMX ist eine tolle Sache, wenn man ein Projekt auf der grünen Wiese beginnt. Um in Größenordnungen Bestandsanwendungen portieren zu können, hätte es aber mehr Kompatibilität zur VCL gebraucht. So jedoch existieren beide Frameworks nebeneinander her und es gibt praktisch keinen Austausch zwischen beiden. Je nachdem wie ein Bestandsprojekt aufgebaut ist, ob du viele Drittanbieter-Frameworks wie TMS oder DevExpress drin hast, ist eine Portierung auf FMX schwierig bis unmöglich.

CrossVCL halte ich für solche Szenarien für den besseren Weg. Harry Stahl hat da vor drei Jahren mal ein schönes Demovideo gemacht: https://www.youtube.com/watch?v=jwoRxprs7hQ

Leider hintertreibt Emba CrossVCL in mehrfacher Hinsicht. Zum einen gibt es anders als bei FMX seinerzeit keine Unterstützung für den Entwickler und zweitens ist der Linux-Compiler nur in der Enterprise-Edition enthalten. Deren Mehrpreis ist einfach zu hoch wenn man nur dieses eine zusätzliche Feature ggü. der Pro benötigt.

Ich weiß nicht ob sich Emba damit wirklich einen Gefallen tut. Auf der einen Seite wenn man auf die Emba-Webseite schaut, dann hängen sie den Linux- und MacOS-Support groß auf. Schaut man aber genauer hin, beschränkt sich das auf Konsolen-Programme und FMX und das eben auch nur in den beiden obersten Editionen. Denn wenn du wirklich die Unterstützung für Linux und/oder MacOS bringen musst und damit sowieso ein riesiger Aufwand für die Portierung verbunden ist, dann kannst du auch gleich die ganze Entwicklungsumgebung ersetzen.

[Rollo62]

Ich versuche die Mega-Frameworks TMS und DevExpress so gut es geht rauszuwerfen, um flexibler zu sein.
Was davon nutz man wirklich, vielleicht 10 % ?

Ok, wenn Du im Projekt wirklich 90 % DevExpress verwendest, dann hast Du ein Problem.

Ich versuche seit geraumer Zeit solche Funktionalitäten zu kapseln, da wo es Sinn macht.
Z.B. TMS Diagram Studio ist ein gutes Beispiel.
Das ist sicher zu komplex um selbst zu entwickeln, aber einfach in jede Form zu werfen macht es nahezu unmöglich das wieder rauszuoperieren.

Deshalb mache ich das so
- TMS Diagram Studio verwende ich in einer Form oder Frame, in sich gekapselt.
- Schnittstellen nach außen mache ich über Interfaces, nur aufs nötigste beschränkt, völlig ohne TMS-Komponenten
- Eine Wrapper-Schicht, falls nötig, um alle TMS Klassen gegen eigene Interfaces zu ersetzen
- Am Ende habe ich einen eigenen "Diagram-Frame", den ich in meiner App an zig Stellen nutzen kann, ohne TMS zu tief einzubinden
- Gibt es Veränderungen, dann kann ich die "Implementierung", also das gesamte TMS Diagram Studio, notfalls rauswerfen und gegen was Anderes ersetzen, z.B. eine gekapselte HTML-Browser-Lösung
- Die gesamte App bleibt dadurch lauffähig und ansonsten verhält es sich gleich
- Nur da wo es nicht 100 % kompatibel,ist muss ich das Interface erweitern

Das funktioniert bei mir recht gut, ist natürlich auch ein extremes Beispiel.
In bestehenden Projekten ist das aber wirklich hart.
Trotzdem, wenn die Nutzung solcher Frameworks nur 10 % ist, dann würde ich so eine schrittweise Separierung und Portierung in Betracht ziehen.
Bei 200 Forms ist das natürlich keine leichte Entscheidung, aber vielleicht kann man mit 50 Forms schon eine sinnvoll abgespeckte App hinbekommen.

Ich finde FMX jetzt generell gar nicht so weit weg von der VCL, bis auf den DB Datenbankbereich natürlich schon, da hätte ich mir auch eine kompatible Schicht zu DB-Komponenten gewünscht.
Vielleicht will Embarcadero uns erziehen von DB-Komponenten weg zu Livebinding, was meiner Meinung nach über einen Zwischenstep FMX-DB-Komponenten einfacher wäre.
Was aber wieder Rückwärts-Kompatibilität gegen Spagetticode eintauschen würde, wenn es zig offizielle Versionen gibt, um DB zu nutzen.
Wenn wenigstens Livebindings halten würden, was sie versprechen, aber auch da muss man sich erstmal reinfrickeln.

TMS FNC macht das ja anders und bietet nach wie vor FMX-DB-Komponenten an, was beweist, dass es prinzipiell geht, nur dass sich kaum einer der Sache ernsthaft annimmt.

[Codehunter]

Zitat von Rollo62:

Bei 200 Forms ist das natürlich keine leichte Entscheidung, aber vielleicht kann man mit 50 Forms schon eine sinnvoll abgespeckte App hinbekommen.

Bei 200 würde ich keine Minute zögern und auch nicht so einen Popanz drum machen. Bei uns kannst du da noch mal eine Null dahinter schreiben und auf jedes Form kommen nochmal zwei bis zehn Frames. Sowas meine ich mit gut gereiften Projekten. Da brauchst du einfach mehr und einfachere Unterstützung um so ein Projekt auf andere Plattformen zu wuppen.

Zitat von jaenicke:

Ich finde die Windows Controls und deren Funktionsweise nicht gerade wünschenswert und diese würde ich mir unter Linux als allerletztes wünschen.

Mal ganz ehrlich, ein Button ist hier wie dort ein Button. Dito bei Grids, Comboboxen etc. Zumal CrossVCL ja wo immer möglich die nativen Controls des jeweiligen OS verwendet. Bei Standarddialogen ebenso. Das Hauptargument ist aber, dass die eigene Nutzerschaft genau das so haben will. Wir haben es ja nicht aus Jux und Dallerei so gebaut.

Wobei hier Linux wie Windows eine gemeinsame Krankheit haben: Es gibt vom TOpenDialog gefühlt drölfzigtausend Versionen. Das hab ich bei beiden Systemen ehrlich gesagt nie verstanden, warum muss Windows 11 immernoch den Windows-2000-Dialog anbieten, nur weil das Programm eben jene alten API-Schnittstellen nutzt? Hätte man die nicht so delegieren können dass immer die aktuellen Dialogversionen kommen? Immerhin waren die Öffnen-Dialoge eine echte Verbesserung zwischen den Windows-Versionen. Bei Linux hast du das Problem, dass jedes UI-Framework seine eigene Version mitbringt. Da hast du dann den von GTK, das von Qt, Cinnamon und Gnome haben auch noch mal einen anderen usw.

[himitsu]

Weil man Schnittstellen nicht ändert, eben aus Kompatibilitätsgründen.
Es gibt neue Schnittstellen, bzw. Erweiterungen zur Alten und irgendwann werden Alte eventuell auch mal entsorgt.

Wenn ein Programm die alte API nutzt, dann bekommt es auch den alten Dialog.
Wichtig für Programme, welche an den Dialogen rumfummeln und z.B. eigene Edits oder eine Vorschau dort einfügen.

[Uwe Raabe]

Zitat von Codehunter:

Hätte man die nicht so delegieren können dass immer die aktuellen Dialogversionen kommen?

In der VCL wird das mit UseLatestCommonDialogs realisiert. Das funktioniert aber nur bei Dialogen ohne VCL-Styles, ohne eigene Templates und nicht bei den Events, die so nur von den alten Dialogen unterstützt werden. Vorteil ist hier halt der automatische Fallback.

Wer das nicht braucht kann auch direkt die neuen Dialoge verwenden, was natürlich mit etwas Arbeit und Umdenken verbunden ist. Leider wird eine solche Umstellung häufig vor sich hergeschoben, obwohl die Anwendungen in der Regel schon seit vielen Jahren nicht mehr auf solch alten Windows-Systemen betrieben werden.

[himitsu]

Jupp, ohne UseLatestCommonDialogs werden "einige" Dialoge über die VCL mit TForm nachgebaut.
z.B. ShowMessage

Das ist auch als Fallback drin, für alte Windowse, oder wo jemand schlau sein wollte und z.B. im alten TerminalServer die "neuen" Styles deaktiverte, weil wegen schneller, Win2000 eh besser aussah, oder so,
was aber auch darin mündet, dass in der alten API z.B. neuen Dialoge/Komponenten nicht vorhanden sind, wie z.B. der TaskDialog oder die neuen FileOpenDialoge.
Die neuen APIs machen dann oft nichts und tun einfach so, als hätte man Abbrechen gedrückt.

Genauso kann man auch gezielt die VCL-Dialoge erstellen, z.B. via CreateMessageDialog.
Die neuere TaskDialogAPI bietet jetzt auch eine Translation, aber wir haben (noch) diese VCL-Dialoge genutzt um Buttons z.B. mit einem anderem "sprechenderen" Text zu versehen oder sonstwelche VCL-Komponenten drauflegen zu können.
Weil im Text war sowas ja grauenhaft, wenn man da so Sachen schreibt, wie "Willst du das wirklich überschreiben? Ja=Überschreiben, Nein=Name ändern und Abbrechen=nichts machen".




Bei so selbstgemaltem Schrott ala FMX (ohne ) oder Java, sieht das Programm sonstwie aus und hat auch noch sein eigenes Verhalten.
Gut, für jeden kleinen Mist tut heute fast jeder das mit eigenen Skins versehn,
aber was ist grundsätzlich dagegen einzuwenden, wenn viele Programme in einem System sich einheitlich/kompatibel verhalten und auch gleich einheitlich aussehen?



Sowohl Windows, Mac, als auch Linux-GUI-Frameworks haben auch ihre eigenen Design- und Verhaltensvorgaben.
https://learn.microsoft.com/en-us/windows/apps/design/
https://learn.microsoft.com/en-us/wi...design/basics/
https://learn.microsoft.com/en-us/wi...ign-principles
https://learn.microsoft.com/en-us/wi...ide/guidelines
https://learn.microsoft.com/en-us/wi...ace-principles
...
(gut, selbst MS hält sich nicht immer selbst dran)