Ist Delphi so Bedeutungslos ?

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

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

[stahli]

@Codehunter

Ich denke, Du bist etwas vom Thema abgekommen. Dass Desktop- und mobile Geräte unterschiedliche Bedienkonzepte benötigen sollte eigentlich jedem klar sein (außer M$ )

Eigentlich geht es aber ja darum, wie komfortabel wir entwickeln können und wie perfekt die GUI gebaut werden kann. Dafür bietet FMX m.E. eine gute Grundlage (wenngleich noch sehr verbesserungswürdig).

Dem Enduser ist es i.d.R. wurscht, mit welchem Framework ein Programm gebaut wurde. Manche halten es für wichtig, dass das Formular so aussieht wie alle anderen unter dem System, andere wollen das eben nicht und den meisten ist es wahrscheinlich egal.
FM2 sieht (glaube ich) unter Win7 ziemlich "original" aus. Da habe ich noch nicht so aufgepasst, da ich gerne einen subjektiv ansprechenden Style einstelle.

Es gibt noch viele Probleme und Mängel unter FMX, aber nicht von Windows abhängig zu sein, ist doch nicht schlecht. Eine vectorbasierte Oberfläche zu haben hat auch viele Vorteile.

Und letztlich: Die VCL gibt es ja weiter...

[Codehunter]

Dann wird es mit FMX wohl so sein wie vorher mit der CLX: Man sollte erstmal mindestens vier Delphi-Generationen überspringen. Wenns das Framework dann immernoch gibt und aktiv gepflegt wird, dann kann man drüber nachdenken.

Andernfalls verschwende ICH als Emba-Enduser und Entwickler meiner Projekte nur meine Zeit mit der Portierung auf ein totgeborenes Framework. Aber wenn ihr meine Posts mal nachlest dann werdet ihr nicht eine kritische Zeile zu FMX finden außer dass ich skeptisch bin wie zukunftssicher das Framework in Händen von Emba ist.

@p80286: Ich stimme dir zu 80% zu: Die Art, Daten zu handlen wird sich weiterentwickeln. Hat man ja bei Konzepten wie AJAX gesehen, sowas konnte man sich vor 10 Jahren auch noch nicht vorstellen.

@Bernhard: Wenn eine Anwendung "smart" genug ist, sowohl Desktop als auch Mobile zu bedienen, dann ist genau das eingetreten was ich mit dem Ferrari und dem Traktor beschrieben habe. Du kannst sowas bauen, solche Chimären. Doch dir bleiben nur zwei Möglichkeiten: Entweder du brichst alles auf den kleinsten gemeinsamen Nenner runter oder du entwickelst das GUI zweimal. Welche Lösung die bessere ist hängt doch dabei ganz vom Projekt ab. Eine Generallösung gibts dafür nicht. Darum sehe ich die Notwendigkeit eines "General-Delphi" auch nicht.

@p80286: Wenn CLX der falsche Ansatz war, warum wird dann nach "nativen Controls" gerufen? Die CLX hat genau das versucht zu realisieren. Einmal auf Basis von WinAPI und einmal auf Basis von Qt (soweit ich mich erinnere). Es war doch auf anderen Wegen der selbe Ansatz, der heute bei Lazarus versucht wird.

Der Idealfall sieht für mich doch so aus: Man hat verschiedene Desktop-OS (sagen wir mal Linux, MacOS und Windows), die man alle mit ein und dem selben GUI versorgen kann. Und man hat verschiedene Mobile OS (z.B. Android, Maemo, iOS und Windows RT), für die hat man ein Mobile GUI.

Deswegen finde ich es z.B. gut wie man derzeit bei XE2 (was neueres hab ich nicht) weitere Desktop-Plattformen zu einem Projekt hinzufügen kann. So wünschte ich mir das jahrelang wo ich mit D7 gearbeitet habe und nur Win32-Binaries auswerfen konnte.

Man stelle sich das mal aus Anwendersicht vor: Ich kaufe mir ein großes Softwarepaket, z.B. Adobe Photoshop. Eine DVD, eine Lizenz. Und ich kann das Ding in einen Mac oder einen PC schieben, egal ob da Linux oder Windows drauf läuft. Dann wird das Betriebssystem auf einmal nämlich sehr nebensächlich.

Das ist es doch, was Windows so breit am Markt hält: Dass genau das eben NICHT geht. Denn andernfalls würde sich Ottonormal-Buntiklicki-User nämlich recht schnell die Frage stellen: Muss ich mir jetzt für 30 (Einführungspreis) oder 180 (regulärer Preis) Euro ein Windows 8 leisten oder tuts auch ein Ubuntu? Muss ich mir für 2000 Euro einen Mac leisten oder tuts auch ein 700-Euro-PC?

Das Betriebssystem sollte egal sein, austauschbar. DANN können wir uns über Cross-Plattform-Frameworks streiten. JETZT ist es nur Haarspalterei.

[uligerhardt]

Zitat von Codehunter:

Die CLX hat genau das versucht zu realisieren. Einmal auf Basis von WinAPI und einmal auf Basis von Qt (soweit ich mich erinnere).

Soweit ich weiß, war CLX immer Qt, auch unter Windows.

[cookie22]

Zitat von Codehunter:

D...
Der Idealfall sieht für mich doch so aus: Man hat verschiedene Desktop-OS (sagen wir mal Linux, MacOS und Windows), die man alle mit ein und dem selben GUI versorgen kann. Und man hat verschiedene Mobile OS (z.B. Android, Maemo, iOS und Windows RT), für die hat man ein Mobile GUI.

...

Genau damit wirst du erhebliche Probleme bekommen. Jedes OS hat eigene Design-Guidelines. Hälts du dich nicht daran, wird dir im schlimmsten Fall sogar der Zugang zum jeweiligen App-Shop verwehrt. Zumindest ist ein solches Vorgehen ein grober Schlag gegen die jeweilige User Experience. Stell dir vor FM unterstützt sogar noch Linux. Unter Ubuntu könnest du z.B. bestimmte GUI Features gar nicht erfüllen. Als Beispiel fallen mir hier diese versteckten Scrollbars ein. Das heißt dein Programm sieht eben unter allen Betriebssystemen komisch und nicht echt aus.

Eine Windoes RT App mit iOS oder Android unter einen Hut zu bringen dürfte auch schwer werden.

[Phoenix]

Zitat von Codehunter:

Der Idealfall sieht für mich doch so aus: Man hat verschiedene Desktop-OS (sagen wir mal Linux, MacOS und Windows), die man alle mit ein und dem selben GUI versorgen kann. Und man hat verschiedene Mobile OS (z.B. Android, Maemo, iOS und Windows RT), für die hat man ein Mobile GUI.

Dein 'Idealfall' ist das schlimmste, was man seinen Usern zumuten kann.

Als Mac-User will ich, das meine Anwendung die Features von OS X 'richtig' adaptiert, so wie ich es von allen Anwendungen auf meinem Mac auch gewohnt bin.

Als Windows-User will ich, da meine Anwendung die Features von Windows richtig adaptiert, so wie ich es von den anderen Anwendungen auf meinem Windows-System auch gewohnt bin.

Von Linux kann ich hier jetzt nicht reden, weil ich das nicht einsetze.

Aber aus dem Grund baut z.B. Atlassian auch grad SourceTree für Windows als native Windows-Anwendung (damit meine ich jetzt .NET 4.5 und WPF) für Windows richtig neu, und portiert nicht einfach nur die Mac-Anwendung 1:1. Untendrunter wird natürlich viel Code unter der Haube geshared werden.

Der Idealfall sieht also so aus:
Die Logik steckt in einem Teil der Anwendung, die man über die Plattformen hinweg teilen kann. Das GUI ist im Idealfall aber auf jede Plattform extra zugeschnitten und optimiert und nutzt die jeweiligen Features des OS so, dass sich der User dort heimisch fühlt.

Deswegen ist das one-size-fits-it-all (und damit FM) der falscheste Ansatz, den man sich überhaupt vorstellen kann. Viel besser wäre eine API, die es ermöglicht die nativen Elemente des jeweiligen OS direkt anzusprechen, selber zu Kapseln und somit jede Plattform so zu verwenden, wie sie vorgesehen war.

[Union]

Zitat von Phoenix:

Deswegen ist das one-size-fits-it-all (und damit FM) der falscheste Ansatz, den man sich überhaupt vorstellen kann. Viel besser wäre eine API, die es ermöglicht die nativen Elemente des jeweiligen OS direkt anzusprechen, selber zu Kapseln und somit jede Plattform so zu verwenden, wie sie vorgesehen war.

WORD! Diese Skinning Geschichte ist ein nettes Gimmick, sollte aber unbedingt optional sein. Ich denke noch mit Grausen an SWING