Gerüchte um XE2 Beta-Test

[cookie22]

Darauf läuft aber alles hinaus. Microsoft macht es doch selbst vor mit WPF.

[jaenicke]

Zitat:

Zitat von Stevie (Beitrag 1114941)

Zitat:

Zitat von Phoenix (Beitrag 1114915)

Aus genau diesem Grund empfehlen richtige Cross-Platform Entwickler ja auch, seine Anwendung mehrschichtig aufzubauen, UI von Logik zu trennen und für jedes System eine native GUI mit dem jeweiligen am besten passenden Toolkit zu erstellen, und den non-Gui-Code hinten halt wiederzuverwenden.

Was man dann ja wohl vergessen kann...

Ich habe es zwar nicht ausprobiert (dann dürfte ich ja eh nix dazu schreiben), aber ich sehe nichts was dagegen spricht, es sei denn du willst einen visuellen Designer. Denn schließlich kannst du Code für die Plattform schreiben und kommst also auch sicher an Bibliotheken der Plattform heran. Du kannst also vermutlich einfach quasi "non-Firemonkey" entwickeln. :mrgreen:

[Phoenix]

Zitat:

Zitat von Stevie (Beitrag 1114941)

Zitat:

Zitat von Phoenix (Beitrag 1114915)

Aus genau diesem Grund empfehlen richtige Cross-Platform Entwickler ja auch, seine Anwendung mehrschichtig aufzubauen, UI von Logik zu trennen und für jedes System eine native GUI mit dem jeweiligen am besten passenden Toolkit zu erstellen, und den non-Gui-Code hinten halt wiederzuverwenden.

Was man dann ja wohl vergessen kann...

Nö. Mit einem bisschen Architektur und vielen Ogern.. erm.. Zwiebeln.. äh.. Schichten, ja genau: Schichten, geht das ohne weiteres.

Man muss halt etwas mehr Zeit da rein stecken.
Mal ein Beispiel: Der Bugtracker von RemObjects war irgenwann mal ein Bugzilla. Dann kam ein Projektsystem (nochmal Bugzilla) dazu. Und ein Supportsystem (nochmal Bugzilla). Im Laufe der Jahre wurde aus dem Projekt- und Bugtracking ein Komglomerat von 6 Bugzilla-Datenbanken, einem angepassten Bugzilla-Frontend und einer Windows-Applikation. Historisch gewachsen eben.

Heute steht dort ein Middle-Tier-Server der die Datenbanken bedient, eine Windows-Applikation, eine Mac-Applikation und eine iPhone & iPad-App. Die Windows-, Mac- und iOS-App teilen sich den gleichen Code für den Zugriff auf den Backend-Server und stellen nur jeweils andere GUIs zur verfügung. Die iOS App sogar gleich zwei unterschiedliche GUIs je nach Gerät. Der Backend-Server teilt auch noch ein bisschen Code mit den Frontend-Apps.

Natürlich war das ein Stück Arbeit, aber herausgekommen sind Apps, die vorne jeweils die bestmögliche User-Experience bieten und dennoch hinten im 'unsichtbaren Teil' mit einem Schlag kollektiv erweitert / gewartet werden können.

Von daher ist das nichts, "Was man dann ja wohl vergessen kann", sondern ein (und meiner Meinung nach der richtige) Weg, Cross-Platform Anwendungen aufzusetzen.

[Stevie]

Zitat:

Zitat von Phoenix (Beitrag 1114986)

Nö. Mit einem bisschen Architektur und vielen Ogern.. erm.. Zwiebeln.. äh.. Schichten, ja genau: Schichten, geht das ohne weiteres.

War eher auf den Einsatz von FireMonkey bezogen... ich bin ja auch nicht son Masochist und benutz Delphi um dann non VCL Windows Anwendungen zu bauen.

[bernau]

Zitat:

Zitat von Stevie (Beitrag 1114941)

Und genau das hat mich damals schon genervt.

So unterschiedlich sind die Geschmäcker. ;-)

Adobe macht es mit Lightroom (gibt auch noch viele andere Programme) vor. Wer würde sich das dunkle Layout standardmäßig einstellen? Aber zum dem einen Programm passt es nun mal sehr gut!

[Daniel]

In Auckland haben sie das XE2 nun erstmalig gezeigt - inkl. einer Demo, wie man eine Anwendung für iOS-Geräte (iPhone, iPad, iPod touch) erstellt:

http://sourceitsoftware.blogspot.com...i-for-ios.html

Interessant ist folgender Aspekt:

Zitat:

The iOS app is full native code, with access to hardware such as gps, accelerometer and camera.

Neu ist hierbei der Begriff "NATIVE", den so in diesem Kontext nicht zu erwarten war.

[Memnarch]

Was das skinnen unter FireMonkey angeht:

Ich bräuchte wahrscheinlich nur eines um unter den systemen das richtige layout zu haben.
Eine funktion mit der ich sämtliche bausteine des aktuellen themes abrufen kann.

Ab windows XP z.B. gibt es eine API funktion, mit der ich da dran komme. Wenn es soetwas auch unter den anderen betriebssystemen gibt, könnte man doch abhängig vom OS die jeweil benötigte funktion nutzen um beim start des programmes alle Theme komponennten einmal abzurufen und in die FireMonkey GUI einzubauen, oder nicht? (Wie gesagt WENN es solche funktionen dort auch gibt die dem User erlauben an die grafiken ranzukommen)

[Ralf Kaiser]

Zitat:

Zitat von Daniel (Beitrag 1115004)

Zitat:

The iOS app is full native code, with access to hardware such as gps, accelerometer and camera.

Neu ist hierbei der Begriff "NATIVE", den so in diesem Kontext nicht zu erwarten war.

:gruebel:

Wie kommt denn da jetzt plötzlich das iPhone rein? War bisher nicht die Rede davon, dass MAC unterstützt wird? Oder gibt es irgendeine Möglichkeit MAC-Anwendungen aufs iPhone zu bringen? (ich habe im Apple-Umfeld 0,00000 Ahnung/Erfahrung)

[Phoenix]

Die Cocoa Touch Klassen von iOS und die Cocoa Klassen des Mac sind sehr unterschiedlich. Da kann man nichts einfach wiederverwednen oder gar eine Mac-Anwendung einfach so auf iOS portieren. Wahrscheinlich kann man einfach gegen die entsprechenden Libraries linken und muss dann halt wie non-VCL gegen die iOS API programmieren.

[Lemmy]

also entweder bekommen die Besucher der World-Tour in Australien Drogen, oder XE2 wird einschlagen:

http://www.deltics.co.nz/blog/?p=735


Gut - bei einer Präsentation kann man viel retuschieren. Ich hoffe echt, das ganze funktioniert mit einer zumindest ausreichenden Stabilität...

Grüße

[mirage228]

Zitat:

Zitat von Lemmy (Beitrag 1115021)

also entweder bekommen die Besucher der World-Tour in Australien Drogen, oder XE2 wird einschlagen:

http://www.deltics.co.nz/blog/?p=735

Schaut gar nicht mal so schlecht aus, hätte jetzt nicht so viele "Überraschungen" erwartet 8-) - Bin mal gespannt wie die LiveBindings und das neue GUI Framework in der Benutzung so sind :)

[TiGü]

Schön wäre ja auch ein assistierender Konverter, um zumindest VCL Formulare mit Standardkomponenten auf FireMonkey umzubasteln.

Und dabei natürlich die Unitnamen die man per uses einbindet entsprechend anpasst!
Sonst wird das ein ganz schönes Gekloppe, bei jeden Formular die Namen der Standardunits entsprechend anzupassen.

[marcoX]

Zitat:

Zitat von TiGü (Beitrag 1115062)

Schön wäre ja auch ein assistierender Konverter, um zumindest VCL Formulare mit Standardkomponenten auf FireMonkey umzubasteln.

Und dabei natürlich die Unitnamen die man per uses einbindet entsprechend anpasst!
Sonst wird das ein ganz schönes Gekloppe, bei jeden Formular die Namen der Standardunits entsprechend anzupassen.

Zumal auch mit Sicherheit auch die Komponenten aus der Win32-Sektion fehlen werden, anders sein werden, anders heissen oder was auch immer (denn die sind ja logischerweise nicht Plattformunabhängig).

Das heißt wer exzessiv PageControls nutzt (was ja nicht selten ist), wird erstmal ein Problem bekommen...

[Daniel]

Zitat:

Zitat von marcoX (Beitrag 1115067)

Das heißt wer exzessiv PageControls nutzt (was ja nicht selten ist), wird erstmal ein Problem bekommen...

Und warum? PageControls gibt es für alle möglichen GUI-Bibliotheken, so dass ich keinen Grund sehe, warum es das für FireMonkey nicht geben könne.

[jaenicke]

Da es auf einem der Screenshots auch zu sehen ist, kann ich bestätigen: Ja, das gibt es auch dort. ;-)

[Bernhard Geyer]

Zitat:

Zitat von Daniel (Beitrag 1115068)

Und warum? PageControls gibt es für alle möglichen GUI-Bibliotheken, so dass ich keinen Grund sehe, warum es das für FireMonkey nicht geben könne.

Evtl. geht es um die Control im Reiter "Win 3.1". Dies gibt es in einigen Apps mit einer "es funktioniert, wieso sollte ich hier umstellen" Verwendung.

[jaenicke]

Man muss die GUI ja ohnehin komplett neu bauen. Insofern ist das egal welche Komponente das vorher war. Hauptsache die neue erfüllt ihren Zweck. ;-)

[Uwe Raabe]

Zitat:

Zitat von TiGü (Beitrag 1115062)

Schön wäre ja auch ein assistierender Konverter, um zumindest VCL Formulare mit Standardkomponenten auf FireMonkey umzubasteln.

Und dabei natürlich die Unitnamen die man per uses einbindet entsprechend anpasst!
Sonst wird das ein ganz schönes Gekloppe, bei jeden Formular die Namen der Standardunits entsprechend anzupassen.

Zitat aus obigen Blog:

Zitat:

(for one thing it resides in the unit FMX.Buttons, as opposed to VCL.Buttons – new namespaces keep the two frameworks apart)

Namespace-Prefixe gibt es auch schon in den XE-Projektoptionen. Eventuell kann man ja auch die schon seit Jahren vorhandenen Aliasnamen für Units missbrauchen.

[implementation]

Zitat:

Zitat von Phoenix (Beitrag 1114915)

Zitat:

Zitat von himitsu (Beitrag 1114911)

Schön wäre es natürlich gewesen, wenn es unter Windows wie mit Windowskomponenten und unter Linux mehr linuxmäßig und auf'm Mac macisch aussehn würde.
So isses ja im Prizip doch immer eine geskinnte Anwendung, welche sich nicht ins System eingliedert.

Dafür gibt es aber kein UI Kit, und um es auf dem jeweiligen System 'Nativ' aussehen zu lassen musst Du jeweils die native API benutzen.

Naja, es existieren ja bereits solche Schichten. Man nehme bspw. das GIMP Tool Kit (GTK): Auf Linux hat's seinen eigenen Stil (den der User auswählen kann und der dann auch GTK-weit vereinheitlicht ist), und auf Windows passt es sich (zumindest in neueren GTK-Versionen) an das Systemdesign an (zu Mac kann ich hier nichts sagen, aber ich gehe davon aus, dass es dort genauso passiert).
Eine andere Option wäre Qt, mit denselben Stärken, nur dem Nachteil, dass das importieren schwieriger ist, da es sich um C++ handelt, statt um C wie bei GTK.
Die LCL packt das ja auch auf diesem Weg: Man setzt auf eine solche Bibliothek.
Schaut euch mal um, wie viele GTK-Anwendungen ihr auf dem Rechner habt. Das wird euch nicht gelingen, denn ihr erkennt sie nicht einmal ;)
Es wundert mich, dass nicht auch Emba auf diesen Stein setzt. Wahrscheinlich ist es die Angst, dann den gleichen Flop zu erleben, wie mit der CLX - oder aber die, vor Lazarus-Usern als "Nachmacher" dazustehen :cyclops:

[jaenicke]

Zitat:

Zitat von implementation (Beitrag 1115162)

Wahrscheinlich ist es die Angst, dann den gleichen Flop zu erleben, wie mit der CLX - oder aber die, vor Lazarus-Usern als "Nachmacher" dazustehen :cyclops:

Mit FireMonkey kannst du deutlich mehr machen als mit solchen Bibliotheken je möglich wäre.

[divBy0]

Auf das Update bin ich echt mal gespannt. FireMonkey klingt echt sehr sehr interessant...

[himitsu]

Ich hatte ja bei FireMonkey erst an was anderes gedacht.

FireFox
FireBird
FireBug
...
und die vielen anderen brennenden Tiere.

Also mal wieder was Zugekauftes, aber eben an nichts Eigenes von Embarcadero. :oops:

[geskill]

Delphi haben die doch auch nur gekauft :P

[FBrust]

Zitat:

Zitat von himitsu (Beitrag 1115227)

Also mal wieder was Zugekauftes, aber eben an nichts Eigenes von Embarcadero. :oops:

Naja, "Rapid Application Development" besteht halt u. a. darin, bereits vorgefertigte Komponenten zu verwenden anstatt das Rad (nicht RAD :mrgreen:)noch mal zu erfinden, in dem Sinne ist FireMonkey eben auch eine Komponente.:wink:

Solange die Integration reibungslos funktioniert, ist dagegen auch nichts zu sagen.

Gruß
Frank

[DeddyH]

Einerseits wird gemeckert, wenn eine Version keine neuen "Killer-Features" enthält, andererseits wird wieder gemeckert, wenn solche dazugekauft und eingebaut werden. Wollte man das ganze Zeug von Grund auf selbst schreiben, gäbe es wohl nur alle paar Jahre neue Delphi-Versionen.

[Nersgatt]

Ich finde nichts dabei, Dinge zuzukaufen. Wir überlegen uns in der Firma auch öfters "was kommt uns billiger? Komponente zukaufen oder selbst schreiben." Wenn wird zu dem Schluss kommen, dass zukaufen günstiger wird, wird halt zugekauft. Warum auch nicht.

[MEissing]

Zitat:

Zitat von himitsu (Beitrag 1115227)

Also mal wieder was Zugekauftes, aber eben an nichts Eigenes von Embarcadero. :oops:

Es ist ja *NICHT* so, dass wir bei FireMonkey nichts verbessert haben.

Das geht weiter, als KSDev es je in Produkte gegossen hat.

[bernau]

Zitat:

Zitat von himitsu (Beitrag 1115227)

Also mal wieder was Zugekauftes, aber eben an nichts Eigenes von Embarcadero. :oops:

Zugekauftes ist erst mal nicht schlecht. Solange das Zugekaufte auch in den nächsten Versionen von Delphi bleibt.

Ein Absolutes NoGo ist, wenn ich die mitgelieferten Komponenten verwende und in der nächsten Version muss ich mir diese zusätzlich Kaufen, weil diese nicht mehr bei Delphi mitgeliefert werden.

[creed steiger]

Zitat:

Zitat von jaenicke (Beitrag 1115172)

Zitat:

Zitat von implementation (Beitrag 1115162)

Wahrscheinlich ist es die Angst, dann den gleichen Flop zu erleben, wie mit der CLX - oder aber die, vor Lazarus-Usern als "Nachmacher" dazustehen :cyclops:

Mit FireMonkey kannst du deutlich mehr machen als mit solchen Bibliotheken je möglich wäre.

Von der Optik her sicherlich,aber GTK/Qt bestehen schon aus ein bissl mehr als nur Oberfläche.
(und Firemonkey/DXScene ist halt hauptsächlich nur der graphische Kram)

[cookie22]

Ich finde es macht nun auch einen riesen Unterschied, ob nun nutzloses Zeug zugekauft wird oder aber etwas sinnvolles wie Fire Monkey.

[Memnarch]

Zitat:

Zitat von himitsu (Beitrag 1115227)

FireBird

Und dan gibts noch den Bruder ThunderBird, der brennt nicht, der hat nur nen Fetisch für Starkstromleitungen :stupid:

[mkinzler]

Der hiess ja ursprünglich FireBird; wurde dann aber wegen dem DBMS umbenannt.

[implementation]

Zitat:

Zitat von mkinzler (Beitrag 1115260)

Der hiess ja ursprünglich FireBird; wurde dann aber wegen dem DBMS umbenannt.

War FireBird nicht als Name für die ganze Suite gedacht, also Firefox, Thunderbird usw. in einem Paket?

Aus der englischen Wikipedia:

Zitat:

The Firefox project has undergone several name changes. Originally titled Phoenix, it was renamed because of trademark issues with Phoenix Technologies. The replacement name, Firebird, provoked an intense response from the Firebird free database software project.[20][21][22] In response, the Mozilla Foundation stated that the browser should always bear the name Mozilla Firebird to avoid confusion with the database software. After further pressure from the database server's development community, on February 9, 2004, Mozilla Firebird became Mozilla Firefox,[23] often referred to as simply Firefox. Mozilla prefers that Firefox be abbreviated as Fx or fx, though it is often abbreviated as FF.[24] The Firefox project went through many versions before 1.0 was released on November 9, 2004. After a series of stability and security fixes, the Mozilla Foundation released its first major update, Firefox version 1.5, on November 29, 2005. Firefox 1.5.0.12 is the final version officially supported under Windows 95.

Also der Browser :stupid:

[marcoX]

Zitat:

Zitat von mkinzler (Beitrag 1115260)

Der hiess ja ursprünglich FireBird; wurde dann aber wegen dem DBMS umbenannt.

Und davor hieß er wiederrum Phoenix, was dann mit dem Bios-Hersteller Probleme gab.

In Sachen Markenrecht sind die Mozilla-Jungs nicht so wirklich auf der Palme :D

[marcoX]

http://www.youtube.com/watch?v=Txf9tJl2jDg

[bernau]

Zitat:

Zitat von marcoX (Beitrag 1115275)

http://www.youtube.com/watch?v=Txf9tJl2jDg

Das sieht ja schon mal richtig gut aus!

[Memnarch]

Musste gerade feststellen das selbst D7 schon warnungen zu platfrom spezifischen abhängigkeiten gibt die crossplattform verhindern XD

[himitsu]

Zitat:

Zitat von Memnarch (Beitrag 1115283)

Musste gerade feststellen das selbst D7 schon warnungen zu platfrom spezifischen abhängigkeiten gibt die crossplattform verhindern XD

Das stammt noch vom Kylix.

Damals ja noch zwei getrennte IDEs
- Kylix (IDE und Compiler für Linux)
- Delphi (IDE und Compiler für Windows)

Darum meckert auch D7 schon.

Wie war das noch ... Kylix 3 und Delphi 7 waren etwa gleich alt?



XE2 soll dann eine Windows IDE werden (erstmal bleiben), welcher aber auch für Linux, Mac, iPhone und Co. kompilieren kann.

Da ja nun die IDE vermutlich nicht (nativ) in Mac/Linux/iPhone läuft,
wie sieht das da eigentlich mit dem Remotedebuger aus?

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1115290)

Da ja nun die IDE vermutlich nicht (nativ) in Mac/Linux/iPhone läuft,
wie sieht das da eigentlich mit dem Remotedebuger aus?

Genau so ist das angedacht gewesen. IDE unter Windows, Remote Debugger unter anderen Plattformen. Für welche Plattformen tatsächlich einer dabei ist, wirst du dann ja sehen. ;-)

Leider sieht man die Auswirkungen von Cross Plattform schon im Remote Debugger von Delphi XE...
Unicodestrings werden nur halb angezeigt, er stürzt beim Aufklappen von Klassen sehr oft ab, ...

Und die Übertragungsgeschwindigkeit ist unter aller Kanone, weil winzigste Pakete (offenbar z.B. alle lokalen Variablen einzeln angefordert und übermittelt) geschickt werden, ...
Derzeit ist es echt eine Qual damit zu arbeiten, ich hoffe das wurde verbessert...

[himitsu]

Das Einzige Mal, wo ich den remotedebugger nutzen wollte, da ging es nicht. :cry:

Delphi via RemoteDesktop auf Terminalserver und Programm lokal.