Delphi Community Edition

[jaenicke]

Ganz ehrlich:
Ich arbeite sehr gerne mit Delphi und Pascal allgemein. Aber wenn du nur auf dem Mac und mit iOS unterwegs bist, würde ich davon abraten.
Denn wie Schokohase schon geschrieben hat benötigst du XCode auf dem Mac, das dann Remote von Delphi unter Windows angesteuert werden muss. Und am Mac wiederum hängt dann das iOS Gerät.

Es gibt ja viele Umgebungen, die direkt auf dem Mac laufen, z.B. Remobjects Fire (kostenlos mit Swift als Sprache) oder auch direkt XCode. Das ist damit schon angenehmer. Delphi ist vor allem von Vorteil, wenn man für mehrere Plattformen entwickelt.

[Tauschi]

ja, erst einmal Danke.
XCode habe ich auf dem Mac.
Soll über den Hobbybereich nicht mehr hinausgehen.
Habe jetzt erst einmal einen Ansatzpunkt...

[toenne]

Ich hatte mit der 10.3.3 CE das gleiche Problem - danke für die Lösung!
Das heisst aber im Umkehrschluss dass Aero aktiv sein muss um die IDE zu nutzen? Denn dann fliegt die 10.3.3 wieder runter.
Oder gibts einen Workaround die IDE auch ohne Aero zu nutzen?
Danke!

[himitsu]

Ohne die Designs fehlen die neuen Common Controls im Windows.
Das betrifft z.B. das ImageList, ListView, RichEdit (alte vs. neue Version), den TaskDialog (ganz neu), sowie die "modernen" Such- und Dateidialoge ... den alten Schrott kann man auch kaum bedienen, vor allem bei der Verzeichnisauswahl.
Die alten "Versionen" sehen nicht nur anders aus, sie besitzen auch unterschiedliche APIs. (andere Schnittstellen und neue Funktionen)
z.B. die ScrollBar nur 16 Bit anstatt Neu zusätzlich 32 Bit, für die Position.
https://docs.microsoft.com/en-us/win...ntrol-versions

Wir hatten einen Kunden, der im RDP-Server das deaktiviert hatte, aber er hat inzwischen eingesehen, dass es einfach nicht mehr zuzumuten ist. Ebenso wurden auch gerade die letzten XP ausgemustert und der LegacyCode wird die nächsten größeren Änderungen nicht mehr überleben (beim Umzug von XE auf 10.x), bzw. wurde teilweise schon entfernt.

Bei Neutentwicklungen verweigere ich nun auch schon eine Zeit lang jegliche Unterstüzung oder umständlichen LegacyCode. (der Kunde darf es gern teuer kaufen, wenn es unbedingt sein muß)
Sowie Vista und Davor wird auch nicht mehr unterstützt. Bei eigenen Programmen werden auch schonmal ganz "moderne" APIs genutzt, womit praktisch auch Windows 7/8 (bis auf Ausnahmen) per se nicht mehr unterstützt wird.

[jaenicke]

Zitat:

Zitat von toenne (Beitrag 1472244)

Das heisst aber im Umkehrschluss dass Aero aktiv sein muss um die IDE zu nutzen?

Es sieht ohne eben nicht so schön aus und die Oberfläche der IDE ist (wie auch jedes andere Programm) spürbar langsamer.
Aber das ist ja logisch, denn durch das Deaktivieren von Aero müssen die Oberflächen der Fenster durch die CPU gerendert werden statt durch die dafür ausgelegte GPU... von daher sollte man Aero ohnehin nur im Notfall deaktivieren, z.B. wenn die Grafikkarte nicht gut genug dafür ist.

[himitsu]

Wenn es um die Leistung geht, dann kann man die Fenster-/Menü-Animationen, Aero-Peek und die Aero-Transparenzen deaktivieren, das macht schon enorm viel aus.
Selbst auf einem winzigen Intel Celeron J3455 mit HD Graphics 500 via VNC/RDP/TeamViewer, z.B. in einer VM auf der Synology.
https://en.wikichip.org/wiki/intel/celeron/j3455

[Codehunter]

Zitat:

Zitat von jaenicke (Beitrag 1472255)

Es sieht ohne eben nicht so schön aus und die Oberfläche der IDE ist (wie auch jedes andere Programm) spürbar langsamer.
Aber das ist ja logisch, denn durch das Deaktivieren von Aero müssen die Oberflächen der Fenster durch die CPU gerendert werden statt durch die dafür ausgelegte GPU... von daher sollte man Aero ohnehin nur im Notfall deaktivieren, z.B. wenn die Grafikkarte nicht gut genug dafür ist.

Zu jeder Regel gibt es eine Ausnahme, in dem Fall eine besonders krasse: Läuft die Anwendung in einer VM, wird alle Grafik auf der CPU erzeugt, auch die eigentlich GPU-beschleunigte. Deshalb laufen alle GDI+-, D2D- und DirectDraw-Funktionen teilweise extrem langsamer als die alte GDI.

[jaenicke]

Zitat:

Zitat von Codehunter (Beitrag 1472262)

Läuft die Anwendung in einer VM, wird alle Grafik auf der CPU erzeugt, auch die eigentlich GPU-beschleunigte. Deshalb laufen alle GDI+-, D2D- und DirectDraw-Funktionen teilweise extrem langsamer als die alte GDI.

Also bei mir ist die CPU-Last sehr gering, wenn ich in einer VM (in dem Fall Hyper-V) z.B. Fenster bewege, die GPU-Last hingegen geht hoch. Und sowohl VMWare als auch VirtualBox unterstützen doch auch Hardwarebeschleunigung für die Grafikkarte. Ich habe damit keinerlei Performanceprobleme.

In welcher Konstellation ist das denn so?

[Uwe Raabe]

Zitat:

Zitat von jaenicke (Beitrag 1472275)

Also bei mir ist die CPU-Last sehr gering, wenn ich in einer VM (in dem Fall Hyper-V) z.B. Fenster bewege, die GPU-Last hingegen geht hoch. Und sowohl VMWare als auch VirtualBox unterstützen doch auch Hardwarebeschleunigung für die Grafikkarte. Ich habe damit keinerlei Performanceprobleme.

Kann ich für VMWare auch bestätigen. Es ist kein merkbarer Unterschied zwischen einem Delphi auf Bare Metal und einer auf derselben Hardware laufenden VM - und davon gibt es hier einige. Kommt vielleicht auch auf die Hardwareausstattung an.

[MichaelT]

Deine 'Empfehlung' deckt sich mit meiner Erfahrung über einen Zeitraum von mehreren Jahren.

Mein Mac ist nicht mehr up tod ate und damit auch nicht mein XCode, weswegen ich über das Debugging eines iOS Devices übers Netz nicht viel sagen kann. Ob das überhaupt (schon) geht, darüber kann ich nichts sagen. Schätze aber nicht, dass die Stabilität beim Debuggen zunimmt.

Eine kleine Anmerkung noch zu Water resp. Fire. Wenn der Debugger beim Breakpoint nicht hält, dann muss von LLDB Debugger auf den internen umstellen. RO sind sehr bemüht auch mithilfe des Mono Unterbaus auch, wie in meinem Falle, ältere OS Versionen zu unterstützen.

Als Einzelner eine heterogene Infrastruktur up to date zu halten ist ein Hobby von jungen ambitionierten und wissbegierigen Sysadmins. Es macht tatsächlich Sinn zumindest Mobile und Desktop zu separieren. Wenn man es schafft alles mit einer Entwicklungsumgebung zu bedienen, umso besser.

Pro Plattform kann man heute schon sagen 'Mac ist Mac und Schnaps ist Schnaps'. Der Aufwand in eine neue Plattform einzusteigen oder dorthin umzusteigen ist schon hoch. Es geht mal nur einen nach der anderen. Die letzten 10 Jahre und die Dekade zuvor waren aus der Perspektive des Aufbruchs historisch einmalig.

Zitat:

Zitat von jaenicke (Beitrag 1443540)

Ganz ehrlich:
Ich arbeite sehr gerne mit Delphi und Pascal allgemein. Aber wenn du nur auf dem Mac und mit iOS unterwegs bist, würde ich davon abraten.
Denn wie Schokohase schon geschrieben hat benötigst du XCode auf dem Mac, das dann Remote von Delphi unter Windows angesteuert werden muss. Und am Mac wiederum hängt dann das iOS Gerät.

Es gibt ja viele Umgebungen, die direkt auf dem Mac laufen, z.B. Remobjects Fire (kostenlos mit Swift als Sprache) oder auch direkt XCode. Das ist damit schon angenehmer. Delphi ist vor allem von Vorteil, wenn man für mehrere Plattformen entwickelt.