Ist Delphi so Bedeutungslos ?

[bernhard_LA]

Zitat:

one-size-fits-it-all (und damit FM) der falscheste Ansatz

sehe ich nicht so.

Im VW-Konzern gibt es guten TDI Diesel Motor in allen Plattformen, warum : weil gut und günstig; REUSE statt REINVENT THE WHEEL
Wer als Software Entwickler verschiedene Hardware Plattformen oder Betriebsysteme bedienen muss und mal die betriebswirtschaftliche Kostenbrille aufsetzt verzichtet gerne auf so manches Feature.
Klar man kann alle Features einbauen solange der Markt/Kunde bezahlt.

[Popov]

Zitat von 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.

Sowas sollte man nicht kritisieren, CLX meine ich. Ok, es ist nichts draus geworden, aber hätte ich damals Geld gehabt, hätte ich aufgrund der Entscheidung paar Aktien von Borland gekauft. So sicher war ich mir damals, dass es ein Erfolg wird. Theoretisch hätte es klappen müssen.

Erfolgreich wird man nicht da wo andere Erfolgreich sind. Das klappt nur selten wenn man Microsoft heißt. Ansonsten muss man neue Gebiete erschließen. Also wünschen wir FMX viel Erfolg.

[implementation]

Zitat von Phoenix:

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

Unter X11-Umgebungen (meistverwendete Display-Server-Familie unter GNU/Linux und *BSD) kann man in der Regel von folgendem ausgehen:

• Entweder den eingestellten GTK-Style oder den eingestellten Qt-Style übernehmen. Meistens läuft das aufs gleiche raus (eines von beiden wird einen Kompatibilitätsstyle zum jeweils anderen eingestellt haben). Ein eigener Programmstyle, der sich nicht an den Systemstyle anpasst, ist No-Go.
• Der Style kann manchmal auch ganz schön schwer nachzubilden sein, siehe cookie22's Beispiel mit den Ubuntu-Scrollbars.
• Es gibt nicht wenige User, die einen Tiling Manager benutzen. Daher ist es absolutes No-Go, dem Fenster eine feste Größe zu geben, auf die es besteht. Das mag der Tiling-WM dann nämlich gar nicht, bzw. es sieht einfach besch*ssen aus.

Das mit dem Style könnte ganz schön hart für Firemonkey werden. Denn es gibt nicht nur einen oder zwei GTK- und Qt-Styles, sondern sehr viele mehr, mit dreistellig muss man rechnen, vierstellig kann es auch schnell werden. Viel Spaß dabei

[Bernhard Geyer]

Zitat von 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.

FXM ist schon weiter als CLX. CLX war in D6 die aktive Technik und schon mit D7 wurde der abgesang eingeleitet als man auf VCL.NET setzte und hier schon einen Beta-Compiler bereit gestellt hat. VCL.NET gabs in D2005 und D2006 und wurde da schon wieder mehr oder minder schrittweise eingestellt.

Zitat von Codehunter:

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

GUI wird 2* entwickelt, aber die GUI-Komponenten basieren auf dem gleichen Framework. VCL könnte auch für Touch-Oberflächen gehen. Mit XEx hat man ja den Touch-Support eingebaut.

Zitat von Codehunter:

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

Man hat sich aber mit der QT eine Komplexität ins Boot geholt die nicht zu beherrschen gewesen wäre. AFAIK wurde Qt mehrmals komplett umgebaut. Wie hoch wäre wohl der Aufwand gewesen die CLX-Philosophie auf die geänterte Qt-Philosophie umzusetzen? Wenn schon native dann mit weniger

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.

Eigentlich brauhst du eine 3-teilung: Desktop/Tablet/Smartphone

Zitat von Codehunter:

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

Kommt doch. HTML5 liefert doch die Plattform das hiermit zu relisieren. Du hast nur den Nachteils das man JavaScript können muss. Uns JS ist nicht gerade eine Programmiersprachentechnische Schönheit.

[Daniel]

Gut - es gibt offensichtlich sehr unterschiedliche Ansichten, wie mit dem Thema "mehrere Plattformen" umzugehen sei.

Ich fürchte nur, dass sich die Diskussion hier im Kreise dreht.

[Codehunter]

Zitat von Daniel:

Ich fürchte nur, dass sich die Diskussion hier im Kreise dreht.

Das scheint mir auch so. Ich habe nur etwas weiter ausgeholt und die CLX als warnendes Beispiel hochgekramt. An Vcl.Net habe ich gar nicht gedacht, da selbst nie verwendet. Aber das wäre das nächste Negativbeispiel.

Ich mag mir gar nicht ausmalen, wenn Borland damals die selbe Ausdauer bei der VCL bewiesen hätte wie später bei den diversen Cross-Frameworks, ob es Delphi heute überhaupt noch geben würde.

Fakt ist aber, die VCL war ein geniales Konstrukt für ihre Zeit und sie war zukunftsfähig. FMX wünsche ich das selbe (auch wenn ich deren Namen ziemlich "affig" finde). Vorallem aber wünsche ich Emba Weitsicht, Programmiergeschick und Ausdauer.

[cookie22]

Solange die Programme nicht zu mindest "Native" aussehen, wird das nicht passieren.

[Lemmy]

Zitat von Codehunter:

Zitat von Daniel:

Ich fürchte nur, dass sich die Diskussion hier im Kreise dreht.

Das scheint mir auch so.

Hat denn irgend eine der vorangegangenen n-1 Diskussionen zu diesem Thema irgend was anderes ergeben? Und falls das nicht klar ist - das war jetzt eine rhetorische Frage!

Zitat von Codehunter:

Ich habe nur etwas weiter ausgeholt und die CLX als warnendes Beispiel hochgekramt. An Vcl.Net habe ich gar nicht gedacht, da selbst nie verwendet. Aber das wäre das nächste Negativbeispiel.

Auf der letzten EKON hat Ray Konopka was ziemlich cooles gesagt:

Im Grunde machen doch alle großen Firmen (Microsoft, Apple,...) das selbe: Irgend ein neues Betriebssystem, ein Bedienkonzept, eine API, Programmiersprache wird mit relativ überschaubarem (finanziellem) AUfwand entwickelt und wie er damals sagte "gegen die Wand geworfen und geschaut ob das kleben bleibt" (frei übersetzt). Wenn das passt und angenommen wird, dann kann die Firma Geld damit verdienen, wenn nicht und die "SchÜÜße" von der Wand fällt, dann kommt halt das nächste...

Das Problem ist, dass Borland, Codegear und jetzt auch Embarcadero schlicht nie die Mittel und Möglichkeiten hatten und haben wie die anderen großen. Und im Grunde ist Delphi angezählt: CLX, VCL.NET - alles Rohrkrepierer gewesen. Irgend wann fehlen die Ideen, die Mittel und dann auch die Leute (Motivation?) die mit neuen Ideen das Produkt nach vorne bringen können.

Ich gebe auch zu: Ich hatte mir mehr von der CLX und von Kylix erhofft. Aber es war schlicht die falsche Zeit und der falsche Ansatz. FMX steht da schon komplett anders da: Der technische Unterbau scheint im Gegensatz zur CLX zu passen (kein Versuch das Windows-Messaging-System auf Linux zu übertragen) und die Plattformen sind finanziell lukrativer. Dazu noch ein paar coole Features (vektorbasiertes Desing).

Und ob FMX an der Wand kleben bleibt, das wird sich zeigen, Embarcadero hat hier auf jeden Fall keine schlechte Chancen einen Nischenmarkt zu besetzen - mehr aber auch nicht!

[Unx]

Zitat von Lemmy:

Und ob FMX an der Wand kleben bleibt, das wird sich zeigen, Embarcadero hat hier auf jeden Fall keine schlechte Chancen einen Nischenmarkt zu besetzen - mehr aber auch nicht!

Nischenmarkt schon aber der muss dann aber geteilt werden mit QT QML bzw. QML3D
http://qt-project.org/wiki/Einfuehru...ierung_mit_QML

[Codehunter]

Wenn es euch bei "nativen Controls" nur darum geht, dass ein Button unter jedem OS so aussieht wie ein Button aus z.B. einem Systemdialog des jeweiligen OS, dann ist der Ball doch eigentlich bei den Betriebssystem-Herstellern.

Im Moment ist es doch so: Die Anwendung sagt: Hey Betriebssystem, ich habe hier ein Rechteck. Da hätte ich jetzt gern was drauf gestellt das so aussieht wie ein Button. Und wenn der User was damit anstellt, dann schick mir doch bitte eine Message.

Besser wäre es doch, wenn es so liefe: Hey Betriebssystem, ich habe hier einen Button. Der macht schon das was ich will und was der User macht weiß ich auch schon, im Moment hält er grad die linke Maustaste gedrückt. Nur sieht das Ding noch bissi Sch**ße aus, darum mal mir doch bitte eine Tapete drauf wie es dir beliebt. Muss eben nur so aussehen wie ein gedrückter Button.

Bei einfachen "nativen Controls" wie einem Button ganz easy. Kompliziert wird es z.B. bei Scrollbars. Manche OS haben die Richtungsbuttons oben und unten, andere haben beide Buttons unten, noch andere haben gar keine Buttons. Dann gibt es Interaktion mit der zugehörigen Client-Area. Bei manchen OS rollt die nach unten wenn man die Scrollbar nach oben schiebt (Windows, MacOS) und bei einigen anderen (Meego, Tizen) läuft es Richtungssynchron. Da ist es mit dem Zeichnen des Controls nicht getan, es gibt relativ viel Interaktion.

Mit der Nativität ist es ja innerhalb der Betriebssysteme auch nicht allzu gut bestellt. Man schaue sich doch nur ein aktuelles Windows 7 oder 8 an. Da habe ich innerhalb von 2 Minuten schon mindestens vier verschiedene aber vollkommen native (da per WinAPI aufrufbare) Datei-öffnen-Dialoge gefunden (siehe Anhänge). Und da sieht man teilweise innerhalb des selben Dialogs zwei Comboboxen mit unterschiedlichem Style.

Ich denke, die Anwender wissen schon gar nicht mehr, welcher Control-Style nun nativ vom OS kommt und welcher z.B. aus einem Anwendungsskin stammt. Entscheidend ist nur, dass der User intuitiv mit der Oberfläche klar kommt. Denn nach meiner Meinung sind die OS-Hersteller auch nicht unbedingt die Helden der Usability. Große Suiten wie Photoshop oder Corel Draw haben z.B. die letzten 15 Jahre keine nativen Controls verwendet und wurden trotzdem zu Defakto-Standards.

Grüße
Cody

PS: Das sind keine Screenshots sondern Bildschirmfotos