Ist Delphi so Bedeutungslos ?

[bernau]

Zitat von cookie22:

Gibt es hier in der DP eigentlich Leute die so mutig sind und FM in richtigen Projkten benutzen? Würde mich mal interessieren.

Ich fange grade an. Das Prinzip von FMX finde ich klasse. Ich brauche auch keine Nativen Controls. Finde das wird überbewertet. FMX ist allerdings wirklick noch sehr verbugt, daher ist alles noch in der Testphase. Habe aber schon ein paar komerzielle FMX-Programme gesehen und ich muss sagen, die sehen schon sehr gut aus.

[cookie22]

Mutig mutig.

Zitat von bernau:

Habe aber schon ein paar komerzielle FMX-Programme gesehen und ich muss sagen, die sehen schon sehr gut aus.

Gibt es dazu was im Web. Wenn ja, dann link mal bitte.

Ich persönlich finde nämlich FM sieht nicht sehr schön aus, kann auch an den schlechten Skins liegen die Emba mitliefert oder daran, dass ich Native einfach besser finde.

[Unx]

Zitat von cookie22:

Gibt es dazu was im Web. Wenn ja, dann link mal bitte.

zB VideoMeld von GoldWave http://www.goldwave.com/vmrelease.php

Schön ist es auch wenn man gleich 'Known Test Issues and Solutions' aufführt und schreibt FireMonkey hat da probleme

Wenn man den ScreenShot anschaut sieht es schon bisschen "Flach" aus
http://www.goldwave.com/vmfeatures.php

[bernau]

Zitat von cookie22:

Gibt es dazu was im Web. Wenn ja, dann link mal bitte.

http://erply.com/

[bernau]

Noch mal zur Klarstellung:

FMX hat noch viele Macken. Die müssen weg. Ohne Zweifel. Ich glaube aber, daß sich hier noch eingies tut. Aber immer noch besser als Native-Controls zu verwenden und den kleinsten gemeinsammen Nenner immer berücksichtigen zu müssen.

Und ich frage mich, warum wird sich hier darüber aufgeregt? Wer FMX nicht gut findet kann ja immer noch die VCL verwenden.

[Bernhard Geyer]

Zitat von bernau:

Ich brauche auch keine Nativen Controls. Finde das wird überbewertet.

Es müssen keine nativen Controls sein. Sie dürfen nur nicht wie Fremdkörper wirken.

[cookie22]

Genau deshalb frage ich mich, warum Emba keine gescheiten Skins mitliefert.

Bekommt man irgendwo Skins, die wie Natives aussehen? Ich hab da noch nichts gefunden.

[Codehunter]

Was sind eigentlich "native Controls"? Meint man damit solche, die ursprünglich auf der MFC basieren und quasi per Subclassing an Delphi angepasst wurden? Wo wie das bei den meisten "alten" VCL-Controls ist? TPageControl, TButton usw... Oder meint man damit Controls, die Zeichnen und Messagehandling komplett selbst übernehmen? So wie Toolbar 2000 und deren Ableger?

Das mit "nativen Controls" ist doch nur Augenwischerei. Schaut man mal bei Lazarus vorbei, dann hat man dort verschiedene Zwischenlayer, die die eigentlichen LCL-Controls vom Betriebssystem abstrahieren. Auch TPageControl und TButton. Sind das dann "native Controls" oder nicht?

Ich glaube, wir würden in der Hinsicht noch ewig das Haar in der Suppe suchen und uns um Definitionen streiten. Worum es doch geht ist: Was ist dein Projekt, was ist deine Aufgabe und womit kannst du das am effektivsten und zukunftssichersten lösen?

Zu Kylix-Zeiten dachten auch viele, die unixoiden Desktops wären die Zukunft. Manche Komponentenentwickler sind sogar auf den Zug aufgesprungen. Man was hab ich an CLX-Brei aus den TSynEdit-Sourcen rausoperiert...

Aus meiner Sicht hat Delphi in seiner jetzigen Form im Mobile-Bereich nichts zu suchen. Warum? Man schaue sich doch nur Windows 8 (Non-RT) mal an: Es ist das selbe in Grün, nur anders herum gedacht. Du bringst die Konzepte von Desktop und Mobilgerät nicht plattformübergreifend zusammen. Dafür sind die Parameter zu verschieden. Displaygröße in Relation zur Pixeldichte und damit der Anzahl von Pixeln pro Millimeter zum Bsp: Ab einer gewissen Auflösung sind Mobilgeräte praktisch unbedienbar weil die Controls zu fitzelig werden. Also fängt man an, die GUIs zu skalieren. Feine Sache, die Schriften sind dann super kantengeglättet und edel vom feinsten. Nur was hat man damit rein technisch gewonnen? Nüschts.

Umgekehrt taugen die Bedienkonzepte von Mobilgeräten nichs auf dem Desktop. Niemand schreibt einen Roman per Touchscreen, sondern man wird immer eine Tastatur benutzen. Ebenso war Windows Mobile (der Vorgänger von Phone 7) die Übertragung von Desktop-Bedienkonzepten auf ein Mobilgerät. Es funktionierte genausowenig. Nicht mal die allzu oft als Beispiel angeführte Firma Apple hat die Bedienkonzepte zwischen MacOS und iOS vereinheitlicht. Das Look'nFeel ja, aber nicht die Bedienung. Da bildet bis heute iTunes die Schnittstelle. Sie werden schon wissen warum.

Ich wage daher die Prophezeiung, dass vereinheitlichte Bedienkonzepte entweder grandios scheitern werden oder aber die bisher gewohnte Dynamik und Komplexität von Desktop-Anwendungen radikale Rückschritte erfahren wird.

Niemand käme auf die Idee, mit einem Ferrari 458 Spider einen Pflug über den Acker zu ziehen. Umgekehrt würde niemand mit einem John Deere 9510R auf die Autobahn fahren. Und das obwohl beide annähernd gleich viel PS haben.

Unterschiedliche Geräteklassen brauchen unterschiedliche Bedienkonzepte. Unterschiedliche Bedienkonzepte brauchen unterschiedliche GUI-Frameworks. Und unterschiedliche GUI-Frameworks baut man idealerweise in unterschiedliche Entwicklungsumgebungen. So wie das Werkstatt-Tor für einen John Deere ein bissi größer sein dürfte als das für einen Ferrari Spider.

Ich stelle gar nicht in Abrede, dass Mobilgeräte die Zukunft sind. Aber sie werden niemals den Desktop vollständig verdrängen. Warum also sollte man nicht hergehen und sagen: Hier gibts ein "Delphi for Desktop", hier ein "Delphi for PHP" und dort ein "Delphi for Mobile".

Fazit: Für mich geht Emba mit dem Konzept der "Eierlegenden Wollmilchsau"-IDE den falschen Weg.

[Bernhard Geyer]

Zitat von Codehunter:

Was sind eigentlich "native Controls"? Meint man damit solche, die ursprünglich auf der MFC basieren und quasi per Subclassing an Delphi angepasst wurden? Wo wie das bei den meisten "alten" VCL-Controls ist? TPageControl, TButton usw... Oder meint man damit Controls, die Zeichnen und Messagehandling komplett selbst übernehmen? So wie Toolbar 2000 und deren Ableger?

Es sind die per WinAPI (oder MacOS) direkt vom OS bereitgestellten Komponenten.

Zitat von Codehunter:

Das mit "nativen Controls" ist doch nur Augenwischerei. Schaut man mal bei Lazarus vorbei, dann hat man dort verschiedene Zwischenlayer, die die eigentlichen LCL-Controls vom Betriebssystem abstrahieren. Auch TPageControl und TButton. Sind das dann "native Controls" oder nicht?

Wenn sie letzteendlich das Button oder pagecontrol vom OS nehmen - Ja.

Zitat von Codehunter:

Zu Kylix-Zeiten dachten auch viele, die unixoiden Desktops wären die Zukunft.

Sind sie doch. MacOS - Mach-Kern, Android - Linux-Kern, iOS - Ebenfalls Mach-Kern. Verkaufen sich in Summe besser als die ganzen Windows-Kisten.

Zitat von Codehunter:

Manche Komponentenentwickler sind sogar auf den Zug aufgesprungen. Man was hab ich an CLX-Brei aus den TSynEdit-Sourcen rausoperiert...

CLX war ja der Falsch (oder inkonsiquente) Ansatz. Als man diesen entwickelt hat hat sich Borland zur Powerpoint-Company gewandelt und PP-Folien als Kernkompetenz gesehen.

Zitat von Codehunter:

Ich wage daher die Prophezeiung, dass vereinheitlichte Bedienkonzepte entweder grandios scheitern werden oder aber die bisher gewohnte Dynamik und Komplexität von Desktop-Anwendungen radikale Rückschritte erfahren wird.

Oder die Anwendungen sind smart genug für jede Geräteklase passende GUI bereit zu stellen.

Zitat von Codehunter:

Unterschiedliche Geräteklassen brauchen unterschiedliche Bedienkonzepte. Unterschiedliche Bedienkonzepte brauchen unterschiedliche GUI-Frameworks. Und unterschiedliche GUI-Frameworks baut man idealerweise in unterschiedliche Entwicklungsumgebungen.

Ersten ja, letzten beiden nein. Wir haben mittlweilen Anwendungen aus dem gleichen Framework die beides optimiert bedienen können.

Zitat von Codehunter:

Warum also sollte man nicht hergehen und sagen: Hier gibts ein "Delphi for Desktop" ... und dort ein "Delphi for Mobile".

Macht man doch jetzt. Es gibt Delphi "Normale" und Delphi iOS.

[p80286]

Zitat von Codehunter:

Unterschiedliche Geräteklassen brauchen unterschiedliche Bedienkonzepte. Unterschiedliche Bedienkonzepte brauchen unterschiedliche GUI-Frameworks. Und unterschiedliche GUI-Frameworks baut man idealerweise in unterschiedliche Entwicklungsumgebungen. So wie das Werkstatt-Tor für einen John Deere ein bissi größer sein dürfte als das für einen Ferrari Spider.

Naja,
zum einen ist das UI ja nur etwas was der Benutzer sieht. Was darunter werkelt steht auf einem ganz anderen Blatt. Und wer heute auf seinem Desktop die vollständige DB herunterlädt, weil "es geht doch" der wird morgen auf einem etwas schwachbrüstigeren Mobilgerät schwer vor die Wand laufen.
Was das UI angeht, vor 20(?) Jahren konnte man auch ohne GUI am Rechner arbeiten. Da gab es Schrift statt Symbole. Da hat sich die "Analphabetenoberfläche" auch durchgesetzt.

gruß
K-H