Sind wir veraltet?

[MyRealName]

Zitat von Codehunter:

Zitat von MyRealName:

Und generell finde ich es immer wieder erstaunlich, wie gut alles eigentlich läuft, man muss ja bedenken, dass MS auf alles mögliche an Hardware treffen kann.
Ich selbst will nicht wieder zurück zu Win 3.1 oder Win95 oder was auch immer. Ich habe allerdings auch keine Update Probleme oder so gehabt, da würde ich dann vllt. auch anders denken.

Nimm doch spaßeshalber mal irgendeinen abgelegten Rechner und installier da mal ein Ubuntu, Mint oder Suse Linux. Da wirst du feststellen, dass reibungslose Funktion nichts ist was Windows exklusiv hätte. Wenn man dann länger und intensiver mit Linux unterwegs ist, dann fallen einem bei Windows erst die vielen Unzulänglichkeiten auf. Das war wie gesagt nicht immer so und Linux hat sich seinen schlechten Ruf jahrzehntelang hart erarbeitet. Nur ist davon inzwischen nichts mehr übrig.

Läuft dann da auch Diablo 4, Elder Scrolls Online und Delphi 11 drauf ?

[Rollo62]

Zitat von Codehunter:

Ist das nicht etwas, das man generell mit Software hat? Wenn man sie nutzen will, muss man sich damit auseinander setzen und sich einarbeiten, nur für den neuen Hype.

Das stimmt, was mich aber stört, dass ständig oft unnötige Änderungen in dem UI oder der Funktionalität kommen, welche jahrzehntelang erlerntes Wissen und Prozesse zunichtemachen.

Mein Eindruck ist, dass Microsoft momentan versucht sich zukünftig mit Win11 mehr auf ARM-Tablets auszurichten, was ich natürlich auch nachvollziehen kann, auch dass es dabei größerer Runderneuerungen bedarf.

Zitat von Codehunter:

Mich ärgert es dann, wenn eine Software eine bestimmte andere Software voraussetzt um überhaupt zu laufen. Wenn ich diese andere aber für unbrauchbar befunden habe, fällt meine Wunschsoftware gleich mit hinten runter.

Das ist natürlich fatal, hättest Du mal Beispiele was da verlangt wird, ich hoffe Elektron ist es nicht.

[Codehunter]

Zitat von MyRealName:

Zitat von Codehunter:

Zitat von MyRealName:

Und generell finde ich es immer wieder erstaunlich, wie gut alles eigentlich läuft, man muss ja bedenken, dass MS auf alles mögliche an Hardware treffen kann.
Ich selbst will nicht wieder zurück zu Win 3.1 oder Win95 oder was auch immer. Ich habe allerdings auch keine Update Probleme oder so gehabt, da würde ich dann vllt. auch anders denken.

Nimm doch spaßeshalber mal irgendeinen abgelegten Rechner und installier da mal ein Ubuntu, Mint oder Suse Linux. Da wirst du feststellen, dass reibungslose Funktion nichts ist was Windows exklusiv hätte. Wenn man dann länger und intensiver mit Linux unterwegs ist, dann fallen einem bei Windows erst die vielen Unzulänglichkeiten auf. Das war wie gesagt nicht immer so und Linux hat sich seinen schlechten Ruf jahrzehntelang hart erarbeitet. Nur ist davon inzwischen nichts mehr übrig.

Läuft dann da auch Diablo 4, Elder Scrolls Online und Delphi 11 drauf ?

https://www.pcgameshardware.de/Diabl...ndows-1422860/

https://www.elderscrollsportal.de/ne...nter-linux/980

Delphi 11? Nicht dass ich wüsste. Muss es auch nicht unbedingt. Ich kann mit Delphi in einer Windows-VM gut leben. Aber VCL-GUI-Binaries für Mac und Linux sollte es doch bitteschön ausspucken können.

Zitat von Rollo62:

Zitat von Codehunter:

Ist das nicht etwas, das man generell mit Software hat? Wenn man sie nutzen will, muss man sich damit auseinander setzen und sich einarbeiten, nur für den neuen Hype.

Das stimmt, was mich aber stört, dass ständig oft unnötige Änderungen in dem UI oder der Funktionalität kommen, welche jahrzehntelang erlerntes Wissen und Prozesse zunichtemachen.

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. So war es zumindest bei mir. Wenn du aber nur völlig andere Software bekommst, mit einem anderen Workflow, dann ist der Preis eines Wechsels zu hoch und man tut es sich nicht an.

Zitat von Rollo62:

Mein Eindruck ist, dass Microsoft momentan versucht sich zukünftig mit Win11 mehr auf ARM-Tablets auszurichten, was ich natürlich auch nachvollziehen kann, auch dass es dabei größerer Runderneuerungen bedarf.

In gewisser Weise haben sie dabei das selbe Problem wie wir. Sie haben sich jahrzehntelang auf x86 eingeschossen und jetzt kommt eine andere Architektur in marktrelevanter Größenordnung daher. Hier haben MacOS und Linux die deutlich größere Expertise, weil sie von Anbeginn architekturunabhängig designed waren bzw. Erfahrungen mit Wechseln haben. MacOS ist ja inzwischen auf der vierten Architektur unterwegs nach MC68, PPC und x86 nun ARM. In Windows sind die Verflechtungen mit der CPU größer und ein Windows on ARM läuft noch lang nicht so rund, vorallem nicht mit Software für x86. Das hat Apple immer besser gelöst, denn alte OS9-Programme liefen auf OSX und auch von x86 zu ARM gab es wieder eine brauchbare Laufzeitungebung. Linux löst das Problem anders, aufgrund seines Open Source Ansatzes können die Distributoren selbst Binaries für die einzelnen Architekturen erzeugen und ausliefern.

Zitat von Rollo62:

Zitat von Codehunter:

Mich ärgert es dann, wenn eine Software eine bestimmte andere Software voraussetzt um überhaupt zu laufen. Wenn ich diese andere aber für unbrauchbar befunden habe, fällt meine Wunschsoftware gleich mit hinten runter.

Das ist natürlich fatal, hättest Du mal Beispiele was da verlangt wird, ich hoffe Elektron ist es nicht.

So ins Detail gehen die meistens gar nicht. Da finden sich dann Formulierungen wie "lauffähig z.B. Linux, MacOS oder Windows" (das fettgeschriebene "z.B." halten sie für sehr wichtig...). Bei Referaten, die mit Fachwissen glänzen wollen, wird das manchmal noch durch Sätze wie "der Einsatz von Emulatoren oder Virtualisierungen ist nicht vorzusehen" ergänzt.

[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.

[jaenicke]

Zitat von Codehunter:

Ich kann mit Delphi in einer Windows-VM gut leben. Aber VCL-GUI-Binaries für Mac und Linux sollte es doch bitteschön ausspucken können.

Ich halte den technologischen Vendor-Lock dort erst recht nicht für zielführend. Man geht auf ein anderes Betriebssystem und baut dann den Mist nach, von dem man vorher noch weg wollte?

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

[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.