Delphi XE3?

[Uwe Raabe]

Zitat von Insider2004:

Zitat von jaenicke:

Zitat von Insider2004:

Das ganze Delphi-Konzept beruht darauf, dass GUI und Code stark verdrahtet sind. Deine Betrachtung ist rein theoretisch und mit Delphi nicht zu vereinbaren. Das geht vielleicht in der MFC von MS.

Das geht auch mit Delphi sehr gut. Ich mache das mit Delphi auch. Der GUI-Layer lässt sich so komplett gegen einen anderen Layer austauschen.
Natürlich hat der auch ein gewisses Maß an Logik drin. Aber eben nur so viel wie die GUI benötigt, nichts zu den Daten an sich.

Kannst Du da mal ein Beispiel anhand einer Procedure geben? Kann ich mir nicht vorstellen, wie man den GUI-Layer einfach so austauschen kann.

Wie sollte ein solches Beispiel anhand einer Procedure denn aussehen? Das hat ja nichts mit irgendwelchen Methoden zu tun, sondern mit dem generellen Programmaufbau. Nimm z.B. eine Datenbankanwendung und verlagere die Datenzugriffskomponenten und deren Ereignisse in ein Datenmodul. Nun ist es ein Leichtes, je ein VCL- und FMC-Form zu erstellen, das die Daten in seinen entsprechenden Controls darstellt.

Das Ganze lässt sich auch noch weiter abstrahieren und auf andere Fälle anwenden. Man muss nur konsequent die Programmlogik von der GUI trennen, dann ist ein Austausch der GUI kein Problem.

Da FMX ab XE3 auch Actions unteerstützt, wird ein solches Vorhaben noch einfacher.

[Insider2004]

Ein Beispiel wäre nett. Gibts kein Opensource-Programm wo das verwirklicht wurde?

[mkinzler]

https://radstudiodemos.svn.sourcefor...y/ActionsDemo/

[Darlo]

Zitat von mkinzler:

https://radstudiodemos.svn.sourcefor...y/ActionsDemo/

Bräuchte man nur XE3 . Scheinen aber einige hier zu haben (Vermutung).

[Peter666]

@MEissing: Ich weiß das ist sicher der falsche Thread, aber ich versuch es dennoch: Das große Problem bei FMX ist wohl die Performance. Ich denke, nachdem ich den FMX Code überflogen habe (mehr als überfliegen ist aufgrund des Umfangs eh nicht drin) ist das Grundproblem die Tatsache das da alle Komponenten über das Canvas gerendert werden. An und für sich mache ich das bei unseren (DirectX) Anwendungen auch, aber ich verstehe die unterirdische Performance nicht. Es ist absolut ein Unding, dass eine simple Listbox bei einem Scrollvorgang dermaßen horrende CPU Auslastungen verursacht. Ein Kernproblem (zumindest bei MacOS) liegt im Rendern von Text. Ohne einen Rasterizer wird das sicherlich nicht besser werden. Ist denn in Zukunft geplant etwas an der Geschwindigkeit zu verbessern?

[Insider2004]

In Lazarus haben sie das Performance-Problem nicht.

[mkinzler]

Firemonkey unter Lazarus?

[greenmile]

Jetzt kommen wir doch endlich mal zum Kern. Ich finde den Weg, den EMBA geht, richtig und gut. Aber für mich sind LiveBindings und Win8 Support nur halb so wichtig, Mit XE2 wurde mir etwas versprochen, was nicht 100% funktioniert (= FM), Nun folgt XE3 und plötzlich wird aus einem Produkt (iOS Support, wie in XE2 halbherzig integriert) zwei Produkte. Kann ich Delphi selbst noch mit einer SA oder für 500 EUR für das Upgrade abdecken, kommt nun plötzlich ein zweites Produkt mit ins Spiel. Das sieht für mich wirklich nach Schnupperversion in XE2 aus, das ist nicht korrekt, auch wenn das bei EMBA wahrscheinlich niemanden ernsthaft interessiert. Ich kann nur hoffen, dass die Performance von FM2 endlich auf ein halbwegs akzeptables Niveau angehoben wird und die peinlichen Bugs verschwinden ,dann wird das was. Ansonsten könnte es echt peinlich werden. Es ist fast unmöglich mit FM eine Mac Anwendung zu erstellen der man nicht ansieht, dass sie mit Delphi entwickelt wurde. Es ist wie damals VisualBasic: Nicht performant und eher eine Lachnummer. Und ich mag Delphi!

Aber letztendlich kann man nur abwarten was kommt, es dauert ja nicht mehr lange und vielleicht werden wir ja alle eines besseren belehrt.

[MEissing]

Zitat von Peter666:

@MEissing: Ich weiß das ist sicher der falsche Thread, aber ich versuch es dennoch: Das große Problem bei FMX ist wohl die Performance. Ich denke, nachdem ich den FMX Code überflogen habe (mehr als überfliegen ist aufgrund des Umfangs eh nicht drin) ist das Grundproblem die Tatsache das da alle Komponenten über das Canvas gerendert werden. An und für sich mache ich das bei unseren (DirectX) Anwendungen auch, aber ich verstehe die unterirdische Performance nicht. Es ist absolut ein Unding, dass eine simple Listbox bei einem Scrollvorgang dermaßen horrende CPU Auslastungen verursacht. Ein Kernproblem (zumindest bei MacOS) liegt im Rendern von Text. Ohne einen Rasterizer wird das sicherlich nicht besser werden. Ist denn in Zukunft geplant etwas an der Geschwindigkeit zu verbessern?

Wir haben an der Performance von FM/FM2 deutlich geschraubt. Schick mir ein Testprogramm (vllt mit Tickcounts) und ich lass es mal unter XE2 und XE3 laufen...

[greenmile]

Zitat von MEissing:

Wir haben an der Performance von FM/FM2 deutlich geschraubt. Schick mir ein Testprogramm (vllt mit Tickcounts) und ich lass es mal unter XE2 und XE3 laufen...

Danke, damit wäre eine für mich wichtige Frage geklärt. Hast Du eine Info, wie es mit den anderen "Dingen" aussieht, wie Drag&Drop (im Detail bei der TListBox) unter Mac etc.?