Ist Delphi so Bedeutungslos ?

[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

[uligerhardt]

Zitat von Codehunter:

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 würde sagen, da hast du ein ungünstiges Beispiel gewählt. Die unterschiedlichen Combobox-Looks kommen daher, das du gethemete (1, 4) und ungethemte (2, 3) Anwendungen genommen hast. Nummer 2 ist vermutlich der Öffnen-Dialog von MS Word, also keine API. Und Nummer 1 und 3 kriegt ja man ja nur aus Kompatibiiltätsgründen bei alten Anwendungen zu sehen.

Da bleibt höchstens die Frage, wieso es MS nicht geschafft hat, ohne Kompatibiltätskrücken (Theming abschaltbar, old style Dialoge) auszukommen.

[bernau]

Zitat von Codehunter:

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.

Genau so ist es. Deshalb sind mir Native Controls wurscht.

[Elvis]

Zitat von bernau:

Genau so ist es. Deshalb sind mir Native Controls wurscht.

Hmm, solche Aussagen kann ich unmöglich mit meinem Anspruch für meine Arbeit vereinbaren.
Da rollen sich mir die Fußnägel bis zum Knie.
Wann immer ich Code sehe, der sinnlos Annahmen macht, die nicht beweisbar sind, wird mir ganz schlecht.
"Sinnlos" heißt hier, dass da teilweise mehr Aufwand betrieben wird um etwas zu tun, was aber unter'm Strich schlechter ist. Wenn jmd. zum FileExists manuell nachbauen würde anstatt die OS API dafür zu nehmen, würdest du dem doch einen saftigen Einlauf verpassen.
Und zwar nicht nur weil er Zeit verschwendet, sondern weil er sicherlich nicht an alle Corner cases gedacht hat, die die API-Version kennt. Wer nur wegen ersterem die Schläuche rausholt, hat den falschen Beruf gewählt.

Genauso ist es mit Controls. In neueren Windows-Versionen kann ich in einer Textbox direkt Unicode-Zeichen auswählen, oder man kann die Schreibrichtung umdrehen um 3 Worte Hebräisch zu erfassen.
Oder in OSX geht Drag'n Drop wesentlich weiter als es standardmäßig in Windows passiert. Dort ist der Fenstertitel normalerweise ein Link zur Datei des Dokumentes. Das heißt, ich kann das Icon des Titels einer Preview-Fensters in einen GMail Tab ziehen um das Bild an meine eMail zu hängen.

Solche Kleingeister, die nicht in der Lage sind zu erkennen, dass man als Entwickler kein Recht hat für absolut blödsinnige Gründe all die eingebauten Features komplett wegzuscheißen, haben den Ruf unserer Zunft schon gehörig versaut.

Als Android-User gehen mir diese ganzen beschissenen[1] PhoneGap-Krücken gehörig auf den Zeiger, die nix können, was ich von einer Android-App erwarte. Und der Zurückbutton ist wohl das mindeste, was auf der Strecke bleibt...
Die User, die in G+, Twitter, Facebook Werbung für die App machen würden, fassen solchen Scheiß[1] nur mit Handschuhen an, wenn man keine Alternative hat. Aber man gibt keine gute Bewertung und bewirbt den erstbesten Konkurrenten, der eine richtige App anbietet, selbst wenn sie nur halbsoviel kann.


[1] das ist noch höflich ausgedrückt

[Meflin]

Zitat von Elvis:

Solche Kleingeister, die nicht in der Lage sind zu erkennen, dass man als Entwickler kein Recht hat für absolut blödsinnige Gründe all die eingebauten Features komplett wegzuscheißen, haben den Ruf unserer Zunft schon gehörig versaut.

Als Android-User gehen mir diese ganzen beschissenen[1] PhoneGap-Krücken gehörig auf den Zeiger, die nix können, was ich von einer Android-App erwarte. Und der Zurückbutton ist wohl das mindeste, was auf der Strecke bleibt...

Als ob es bei der UI-Diskussion darauf ankäme, was der Entwickler will. Natürlich ist es dem Benutzer wurscht, ob das native Controls sind oder nicht. Nur werden diese Ansätze wie PhoneGap, Firemonkey und Co eben nie den Grad an User Experience erreichen, den man hat, wenn man auf erstere setzt. Wenn ich so eine App sehe, die im Grunde genausogut im Browser als Webapp laufen könnte, und dafür am besten noch bezahlen soll, dann komme ich mir als Nutzer hauptsächlich verarscht vor. Der Gipfel meiner Erfahrungen war da die DVL-Ergebnisticker-App, die nicht mehr konnte, als die Mobilversion der DVL-Ticker-Webseite, und noch dazu offensichtlicherweise selbst aus nicht mehr bestand, als HTML-Views (keine Push-Notifications für Ergebnisse oder so, nichts). Bloß dass man dafür noch 1,50 bezahlen sollte. Der Einkauf ging dann auch postwendend wieder zurück.

[bernau]

Zitat von Elvis:

Zitat von bernau:

Genau so ist es. Deshalb sind mir Native Controls wurscht.

Hmm, solche Aussagen kann ich unmöglich mit meinem Anspruch für meine Arbeit vereinbaren.

Siehe bitte meine Aussage im Kontext. Ich programmiere das, was der User will. Wenn man sich Photoshop anschaut, dann siehst du keine nativen Controls. Wird aber ohne Ende gekauft. Ein Programm, welches sich heute nicht skinnen lässt, wird nicht gekauft. Warum wollen die User andere Skins? Nicht, weil sie unbedingt mit den nativen Controls arbeiten wollen, sondern weil sie es anders haben möchten. Deshalb sind mir native Controls wurscht. Die optischen Effekte, die FMX mir bietet, werde ich nicht mit nativen Controls erreichen können. Und darauf stehen die User. (Drücke ich jetzt mal genau so pauschal aus)

Verwendest du zugekaufte Komponenten? Grids, TreeCombobox, etc. Wenn ja? Das sind doch auch keine nativen Controls. Oder?

Zitat von Elvis:

Solche Kleingeister, die nicht in der Lage sind zu erkennen, dass man als Entwickler kein Recht hat für absolut blödsinnige Gründe all die eingebauten Features komplett wegzuscheißen, haben den Ruf unserer Zunft schon gehörig versaut.

Ist das nicht eine sehr kleingeistige Ansicht? Der Markt wird es regeln. Was nützen mir hebräische Zeichen, wenn ich (meine Kundschaft) diese nicht brauche?

Zitat von Elvis:

Als Android-User gehen mir diese ganzen beschissenen[1] PhoneGap-Krücken gehörig auf den Zeiger, die nix können, was ich von einer Android-App erwarte. Und der Zurückbutton ist wohl das mindeste, was auf der Strecke bleibt...

Dann kauf dir doch ein iPhone, wenn dir die Android-Apps nicht gefallen.