Sind wir veraltet?

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