Neues iPhone SDK zum download

Auch wieder wahr.

Wieso heisst dann eigentlich das "Ding" dann (UI)Window, wenn es gar keines ist. Hätte man ja auch (UI/NS)Frame oder (besser) Card - um bei Spielkarten zu bleiben - nennen können.

Wahrscheinlich würden wir uns jetzt bei einem modifizierten Appkit beklagen, warum diese und jene Methode nicht mehr geht oder sich anders verhält, man vergleiche einfach mal NSImage und UIImage...

Jörg

Original von kressevadder
Einspruch!

Hinter dem UIKit steckt ein anderes Design als hinter dem AppKit. Die GUI wird mit anderen Konzepten aufgezogen, hat andere Bedienelemente etc.

Hier eine Liste der anderen Konzepte: Knöpfe, Schieber, Scroller, Textfelder, Tabellen, Events, Bilder, Tabs.

Äh, habe ich was vergessen? Ja, Fenster. Die sind wirklich ein anderes Konzept.

Aber was wäre daran so schlimm, wenn jedes Fenster das man auf dem Desktop in der Größe ändern kann einfach fix auf Full-Screen gezoomt wird? und die Titelzeile weggelassen wird weil man eh nicht zoomen kann. Dann wäre man schon fast beim Window-Stack. Und neue Fenster könnten bei orderFront: einfach von der Seite Reinsliden. Einen Window-Stack hat das AppKit ja mit setLevel auch. Und sogar Sheets gibt es. Also alles nur eine Variation von aus dem AppKit Bekanntem.

Also nicht viele andere Konzepte sondern genau eines: Sheets statt frei positionierbare Fenster. Das hätte man m.E. in NSWindow mit 2 oder 3 Einstellungen konfigurierbar machen können.

Und das alles wäre vielleicht auf dem Desktop nützlich.

Dann noch Menüs. Auch die muß man ja nicht zwingend benutzen selbst wenn sie der Werkzeugkasten im IB einfach anbietet. Oder sie wären einfach wirklungslos wenn die App fürs iPhone übersetzt wird. Das merkt man dann sehr schnell

Eine GUI die für die Dicken gemacht ist, lässt sich nicht auf den Taschenkrebs portieren. Das ist ja gerade das "iPhone Feeling", man hat keinen Abklatsch eines klassischen Desktops, sondern ein durchdachtes Konzept um seine Anwendung auf nem kleinen Display zu visualisieren.

Wer sagt denn dass man auf AppKit ausschließlich einen Desktop programmieren kann? Das ist nur eine Frage der Nutzung des Werkzeugkastens. Du kannst ohne weiteres:
* Fenster ohne Titelzeile
* Ohne Toolbar
* Applikationen ohne Menü
* kleine Fenster
schreiben. Muß man nur tun. Braucht also kein neues Konzept sondern nur eine etwas anderen Einsatz der Werkzeuge. Beispiel: FrontRow - das ist keine Desktop-Applikation.

Viele Technologien die es unter OS X gibt, stehen auf dem Telefon nicht zur Verfügung und die sind oft eng mit dem AppKit verzahnt. IMHO würde auch das ne gemeinsame Codebasis für die GUI unmöglich machen.

Welche und warum?

M.E. fehlen nur CoreData und Bindings. Das wäre sicher auch auf dem iPhone sehr praktisch.

Und zum Thema Dicke und Taschenkrebs: das iPhone hat einen Prozessor mit 600 MHz und ich glaube 128 MB RAM. Die ersten NeXT-Maschinen hatten - äh man traut es sich gar nicht zu sagen - 40 MHz und 8 MB RAM. Und auf denen lief schon ein Vorläufer des heutigen AppKit q.e.d.

Aber es ist m.E. müßig darüber zu debattieren. Apple hat nun mal diesen Weg angefangen und wir werden ihn mitgehen.

-- hns

Original von hns
Also nicht viele andere Konzepte sondern genau eines

Ääh, nee.

Mach mal ein ToolTip / MouseOver / Dock oder einen Rechtsklick mit nem iPhone. Oder mach' Shake-to-restart mit einem MacPro...

Die Konzepte sind grundverschieden - primär aus Sicht der Bedienung. Das beinhaltet, dass sich UI-Konzepte nicht 1:1 übertragen lassen. Es ist Absicht und eine der Stärken des Konzepts, dass das komplett neu ist und nicht versucht wurde, ein generisches Kit für alles zu bauen. It's not a bug, it's a feature.

Und selbst wenn sich - rein technisch - einige GUI-Sachen wiederverwenden ließen, kann ich es gut verstehen, dass das nicht gemacht wurde. Hier tritt ein Neuling gegen 20 Jahre gereifte WIMP-Paradigmen an. Auch Apple macht hier neue Erfahrungen und sollte flexibel bleiben. Da ist es doch sinnvoll, sich nicht von Anfang an einen Klotz ans Bein zu binden, oder?

Original von mattik

Original von hns
Also nicht viele andere Konzepte sondern genau eines

Mach mal ein ToolTip / MouseOver / Dock oder einen Rechtsklick mit nem iPhone. Oder mach' Shake-to-restart mit einem MacPro...

Man muss genau andersherum denken: es geht nicht darum alle Desktop-Featuers aufs iPhone zu quetschen und alle Features des AppKits auch real zu nutzen.

Sondern umgekehrt dass man alle Features des iPhone-GUI mit AppKit auf einem Desktop oder eben iPhone realisieren könnte. Nenne mir ein einziges GUI-Feature des iPhones das man nicht mit AppKit bauen/simulieren/nachbilden kann (außer dem Multitouch fürs Vergrößern - und das ließe sich in NSEvent, NSScrollView und NSClipView ergänzen).

D.h. AppKit wäre mächtig genug um alle Neuerungen des iPhone zu realisieren. Daher erschließt sich mir die technische Notwendigkeit für ein neues, leicht inkompatibles GUI-Kit einfach nicht.

Und selbst wenn sich - rein technisch - einige GUI-Sachen wiederverwenden ließen, kann ich es gut verstehen, dass das nicht gemacht wurde. Hier tritt ein Neuling gegen 20 Jahre gereifte WIMP-Paradigmen an. Auch Apple macht hier neue Erfahrungen und sollte flexibel bleiben. Da ist es doch sinnvoll, sich nicht von Anfang an einen Klotz ans Bein zu binden, oder?

Ich bin nach einigem Vergleich einfach zu dem Ergebnis gekommen, dass es nicht nur *einige* GUI-Sachen sind, sondern 90% die sich wiederverwenden ließen.

Und AppKit ist sehr flexibel. Vergleiche mal 10.0 mit 10.5. Da sind Welten dazwischen. Gab es bei 10.0 z.B. Sheets, CoreAnimation, rechte Maustaste/Context Menüs überhaupt schon?

Dafür haben sie m.E. einen anderen Klotz am Bein. Und der heißt Xcode und IB Beta. Alles wird darin verdoppelt. Und in der einen Hälfte vom IB geht es soherum und in der anderen andersherum. Für mich als Developer heißt das dass ich mich in ein neues UIKit und einen neuen IB-Bereich einarbeiten muß. Die alles andere als harmonisch zusammenarbeiten.

Winziges Beispiel: Mache mal aus einem XIB ein NIB. Und dann das gleiche für ein iPhone-XIB...

Hätte man sich m.E. sparen können und trotzdem alle iPhone UI-Features haben.

-- hns

Original von hns
Nenne mir ein einziges GUI-Feature des iPhones das man nicht mit AppKit bauen/simulieren/nachbilden kann (außer dem Multitouch fürs Vergrößern - und das ließe sich in NSEvent, NSScrollView und NSClipView ergänzen).

Nachzubauen bestimmt, aber beispielsweise das Rotieren des ganzen Screens. -- Aber geht es darum?

Du sitzt vor komplett anderer Hardware, da halte ich es für legitim, neue Konzepte einzuführen.

Und AppKit ist sehr flexibel. Vergleiche mal 10.0 mit 10.5. Da sind Welten dazwischen. Gab es bei 10.0 z.B. Sheets, CoreAnimation, rechte Maustaste/Context Menüs überhaupt schon?

Außer CoreAnimation gab's die alle, ja.

Ich stimme dem weitgehend zu: Dass man zwei unterschiedliche Konzepte zu einem Superkonzept abstrahieren und dann wieder in zwei Instanzen konkretisieren kann, bedeutet nicht, dass man dies tun soll.

AppKit und dieses So-Ähnlich-Wie-Cocoa-Jedöns haben zwei völlig unterschiedliche Bedienansätze. Also sind das erst einmal unterschiedliche Konzepte und damit durch unterschiedliche Klassen modellierbar. Und: Code-Reuse muss ja nicht zwingend durch Abstraktion und Vererbung erfolgen.

Alles in Allem dürften wir das übrigens nicht wirklich beurteilen können. Uns fhlen die Informationen und ganz sicher die Erfahrungen. Ich glaube aber nicht, dass in der Montags-Morgens-Konferenz einer der Entwickler mal eben kacken ging und als er zurückkehrte verkündete: "Ich hab's gesehen: Wir machen ein neues Framework!"* Die werden sich sicherlich darüber ein-, vielleicht sogar zweimal unterhalten haben.

* Heine wusste zu berichten, dass man auf der Toilette Deutschlands Zukunft sieht. Die vom iPhone wird sich unterscheiden.

Original von seb2

Original von hns
Nenne mir ein einziges GUI-Feature des iPhones das man nicht mit AppKit bauen/simulieren/nachbilden kann (außer dem Multitouch fürs Vergrößern - und das ließe sich in NSEvent, NSScrollView und NSClipView ergänzen).

Nachzubauen bestimmt, aber beispielsweise das Rotieren des ganzen Screens. -- Aber geht es darum?

Nein. Das gabs übrigens für den Mac... War echt lustig.

Mit Cocoa ist das ein bsichen schwierig, aber da würde eine einfache @property für NSWindow reichen dass das erlaubt ist und der Rest passiert irgendwo im AppKit. Deshalb muss ich als Anwendungsprogrammierer doch nicht auf UIWindow umsteigen wo dann andere gewohnte Dinge fehlen.

Du sitzt vor komplett anderer Hardware, da halte ich es für legitim, neue Konzepte einzuführen.

Was ist daran komplett anders? GUI-Kit-relevant ist doch:

1. Ein Display (zwar nur mit 320x480 pixels aber das ist bei resolution independence ziemlich irrelevant)
2. Meist hochkant - aber mit Lagesensor
3. Ein Eingabegerät das Touch-Events mit Koordinaten liefert. Ob das eine Maus, ein Touchscreen oder ein Tablet ist - jedesmal kommt eine Koordinate und dass ich gedrückt oder losgelassen oder bewegt habe.

Was noch?

Und AppKit ist sehr flexibel. Vergleiche mal 10.0 mit 10.5. Da sind Welten dazwischen. Gab es bei 10.0 z.B. Sheets, CoreAnimation, rechte Maustaste/Context Menüs überhaupt schon?

Außer CoreAnimation gab's die alle, ja.

Ja, habe nochmal geschaut. Also alles bewährte Dinge im AppKit.

-- hns

Ich spiele gerne den Advocatus diaboli wenn mir jemand etwas als völlig anders verkaufen will: "Aus der Ferne betrachtet ist eine Revolution eine Evolution."

Original von Tom9811
AppKit und dieses So-Ähnlich-Wie-Cocoa-Jedöns haben zwei völlig unterschiedliche Bedienansätze. Also sind das erst einmal unterschiedliche Konzepte und damit durch unterschiedliche Klassen modellierbar. Und: Code-Reuse muss ja nicht zwingend durch Abstraktion und Vererbung erfolgen.

Nochmal: was bitte ist daran *völlig* unterschiedlich? Ich habe beidesmal ein Display, ein Pointerdevice. Und ich habe Buttons, Slider, Tabellen usw. über die ich mit dem Pointerdevice etwas auslöse. Und ob die Fenster als Stack oder nebeneinander dargestellt werden bzw. resizable sind oder nicht bedeutet doch nicht dass man eine neue Architektur braucht.

Alles in Allem dürften wir das übrigens nicht wirklich beurteilen können. Uns fhlen die Informationen und ganz sicher die Erfahrungen. Ich glaube aber nicht, dass in der Montags-Morgens-Konferenz einer der Entwickler mal eben kacken ging und als er zurückkehrte verkündete: "Ich hab's gesehen: Wir machen ein neues Framework!"* Die werden sich sicherlich darüber ein-, vielleicht sogar zweimal unterhalten haben.

Ich denke schon dass ich das Ergebnis beurteilen kann weil ich genau diese Erfahrung habe...

Schaue Dir mal mein QuantumSTEP-Projekt und seine Ziele an

Zur Historie können wir wirklich nur spekulieren. Ich denke schon dass sie sich unterhalten haben. Aber es war bekanntlich ein Geheimprojekt unter extremem Zeit&Erfolgsdruck. Und da mag es ihnen aus der Sicht zum Entscheidungszeitpunkt einfacher erschienen sein ein neues UIKit zu erfinden statt das bestehende AppKit zu ergänzen. Auch wenn das m.E. gravierende Nachteile hat.

Ich finde es nur schade dass sich Apple dem umständlichen statt dem technisch eleganten Weg verschrieben hat und damit die NeXT-Philosophie verläßt. Und dass alle davon begeistert sind, dass uns Apple die zweitbeste Lösung gibt.

Wie gesagt - ändern tun wir das nicht.

-- hns

Original von hns
Was ist daran komplett anders? GUI-Kit-relevant ist doch:

1. Ein Display (zwar nur mit 320x480 pixels aber das ist bei resolution independence ziemlich irrelevant)
2. Meist hochkant - aber mit Lagesensor
3. Ein Eingabegerät das Touch-Events mit Koordinaten liefert. Ob das eine Maus, ein Touchscreen oder ein Tablet ist - jedesmal kommt eine Koordinate und dass ich gedrückt oder losgelassen oder bewegt habe.

Fang mit mir nicht das wer-kann-weiter-abstrahieren-Spiel an.

Ich spiele gerne den Advocatus diaboli

Bin ich der einzige, der jetzt an die größte Szene aus den Simpsons denkt?

Ziele sind keine Erfahrung. Mir ist auch nicht bekannt, dass QuantumStep von der Bedienung her irgendwas mit dem iPhone gemein hat.

Was unterschiedlich ist, ist auch schon gesagt worden: Das gesamte Focussing, damit wohl auch das Dispatching. Das Z-Ordering (damit erneut das Dispatching betroffen, weil dies bei Cocoa NSWindow macht).

Genau genommen ist die einzige Gemeinsamkeit, dass ein paar Linien gezeichnet werden.

Wie gesagt: Es ist ganz gut so, dass wir das nicht ändern. (Wobei ich auch nicht die Absicht hatte.)

Ich glaube aber nicht, dass in der Montags-Morgens-Konferenz einer der Entwickler mal eben kacken ging und als er zurückkehrte verkündete: "Ich hab's gesehen: Wir machen ein neues Framework!"

Also wenn man sich die Software die aktuell auf dem iPhone ist so anschaut, dann sieht das ehr so aus als wäre da jemand kacken gegangen uns als er zurück kam hat er gesagt: "Hey Jungs, nächsten Montag bringen wir ein ganz neues Telefon raus - macht mal ein Framework"

Original von Tom9811
Ziele sind keine Erfahrung. Mir ist auch nicht bekannt, dass QuantumStep von der Bedienung her irgendwas mit dem iPhone gemein hat.

Was unterschiedlich ist, ist auch schon gesagt worden: Das gesamte Focussing, damit wohl auch das Dispatching. Das Z-Ordering (damit erneut das Dispatching betroffen, weil dies bei Cocoa NSWindow macht).

Genau genommen ist die einzige Gemeinsamkeit, dass ein paar Linien gezeichnet werden.

Wie gesagt: Es ist ganz gut so, dass wir das nicht ändern. (Wobei ich auch nicht die Absicht hatte.)

ich glaube Du hast Dir überhaupt nicht angeschaut was QuantumSTEP ist und macht, sonst würdest Du nicht zu solchen (abwertenden?) Aussagen kommen ("Ziele sind keine Erfahrungen").

1. An QuantumSTEP wird seit 2003 gearbeitet.

2. Dort sind viele der angesprochenen Themen ins AppKit integriert. Z.B. definierst Du ein Fenster im IB und es wird bei orderFront: auf die volle Größe aufgezogen. Wenn man es noch mit NSAnimation von links oder rechts reinschweben lassen würde, sieht das exakt genauso aus wie es das iPhone macht. Damit ist doch bewiesen dass es geht.

3. Lade mal die Test-Drive-Applikationen und probiere mit der Adresses, Mail oder der Kalenderapplikation "Dates" herum. Das läuft auf Deinem Mac - ohne Simulator.

Die Fenster werden einfach übereinandergelegt (Stack). Und statt dem roten Close-Button könnte da genausogut "Back" oder "Fertig" stehen. Mit etwas gutem Willen (den Du hoffentlich mitbringst sonst), siehst Du die Ähnlichkeit zur Bedienphilosophie des iPhone und dass es wenn man wollte mit nicht allzuhohem Aufwand gleich gemacht werden könnte. Dann probiere es mal ausschließlich mit der Maus und der linken Taste zu bedienen. Dann stelle Dir vor es wäre ein Tochscreen und ein Finger. Und Du wirst merken: es geht auch.

Und dann schaue Dir mal an wann diese Applikationen erstmals veröffentlicht wurden und wann das iPhone herauskam.

Dann können wir gerne weiter reden.

Schönen Abend,
-- hns

PS: damit wir uns nicht nochmal falsch verstehen: ich behaupte nicht dass QuantumSTEP die bessere Bedienung hat oder gar schöner aussieht als beim iPhone. Sondern nur dass man das iPhone-GUI genausogut auf Basis des AppKits hätte machen können. Und das wäre viel besser als dass wir zwei verschiedene GUI-Kits haben.

Das Problem ist mehrschichtig: Sicherlich hätte man mit einiger Abstraktion auf technischer Ebene eine weiter gehende Vereinheitlichung implementieren können als es jetzt der Fall ist. Wenn wir das Ganze auf die Ebene "Wir haben einen Bildschirm mit Zeug drauf und ein Eingabegerät, mit dem ich auf etwas zeigen kann" bringen, passt das sicherlich auf viele Anwendungsfälle. Und sicherlich wird es einige Interface-Widgets geben, die zweckbedingt ähnlich aussehen werden (z.B. wird ein Interface zur Auswahl einer Option aus mehreren Möglichkeiten sicherlich auf verschiedenen Geräten listenähnlicbh aussehen). Aber aus Benutzungssicht ist das eben gerade nicht sinnvoll - Wiederverwendung würde da zu Kompromissen führen, die irgendwie auf mehreren Geräten gehen, aber nirgendwo gut sind. Das ist es gerade nicht, was ist bei Apple sehe. Ein Beispiel ist die iPhone-Slideshow: Das Schieben fühlt sich auf dem iPhone echt gut an. Auf einem großen Rechner ist das weder sinnvoll noch notwendig - ich habe eine Tastatur mit Pfeiltasten, Platz für Buttons etc. Warum sollte Apple da Leute auch noch ermutigen, UI-Code wiederzuverwenden? Ebenso das ganze Neigungs- und Beschleunigungszeug.

Ein Touchscreen und eine Maus mögen technisch beide HID Pointing Devices sein, das Handling und somit auch das Design guter Interfaces dafür sind aber grundverschieden. Leider wissen viele GUI-Designer das immer noch nicht - mit teilweise grausamen Ergebnissen.

Es stimmt schon, dass die Xcode-IB-Beta nicht so richtig tolle ist. Ebenso die Frameworks - perfekt geht anders. Es ist halt eine Beta. Und kostenlos... Apple hat nach massivem Druck einen ersten Schritt in Richtung Öffnung der Plattform getan - ich hätte auch nicht erwartet, dass das alles schon gewachst und poliert ist. Und im Vergleich zu 10.0 ist das Ganze doch gar nicht sooo schlecht...

Original von mattik
... ich habe eine Tastatur mit Pfeiltasten, Platz für Buttons etc. Warum sollte Apple da Leute auch noch ermutigen, UI-Code wiederzuverwenden?...

Ich würde einfach gerne das komplette Know-How übers AppKit wiederverwenden. Intensiven Code-Reuse will ich gar nicht machen, aber ab und zu schon - z.B. von NSView abgeleitete eigene Widgets. Genaugenommen stört mich dass ich für m.E. sehr ähnliche Aufgaben auf einmal zwei ähnliche aber nicht identische Werkzeugkästen brauche und mich mehr mit den Unterschieden beschäftigen muß. Das ist einfach ineffizient und das meine ich mit "zweitbester Lösung" (für den Applikationsentwickler).

Ich komme mir halt so vor wie der Taxi-Chauffeur der seinen Kunden ein völlig neues Erlebnis bieten wollte indem er zweisitzige Cabrios hat. Und dafür war es anscheinend notwendig Gas- und Bremspedal zu vertauschen...

-- hns

Ich spreche nicht abwertend über QuantumStep. Es ist nur nicht das iPhone.

Genau, das Fenster ist ein gutes Beispiel: Überlappende Fenster ständig auf volle Größe zu setzen, um den gleichen Effekt zu bekommen, ist eben haarscharf vorbei programmiert. Das erinnert mich an Windows, das eigentlich auch keine überlappende Fenster benötigt, weil sie so gut wie nie einer benutzt.

Wenn ich keine überlappenden Fenster in der UI habe, dann "frickel'" ich nicht überlappende Fenster hin, bis es passt, sondern ich programmiere keine.

Es ist für diese Frage völlig gleichgültig, seit wann, wer, was, wo, wie bei QuantumStep macht.

Du hast nicht zwei ähnliche Aufgaben. Die UI auf dem iPhone ist völlig anders als die UI auf einem Desktop. Die Lösung des UI (nur darum geht es!), ist daher nicht ähnlich, sondern völlig anders.

Original von Tom9811
Du hast nicht zwei ähnliche Aufgaben. Die UI auf dem iPhone ist völlig anders als die UI auf einem Desktop. Die Lösung des UI (nur darum geht es!), ist daher nicht ähnlich, sondern völlig anders.

Wenn Du unbedingt etwas völlig anderes drin sehen willst und deshalb unbedingt eine völlig andere Lösung willst, habe ich nichts dagegen einzuwenden.

Was mich noch interessieren würde: baust Du für jede Applikation ein neues GUI-Kit? Jede Applikation hat nämlich ein völlig anders UI (vgl. z.B. Xcode mit FrontRow und Pages). Also bräuchte es mit obiger Argumentation drei verschiedene AppKits.

Für mich ist es jedenfalls derart ähnlich dass es meiner Lernfaulheit extrem entgegenkäme, wenn es ein gemeinsames AppKit gäbe. Damit kann ich auch völlig verschiedene UIs hinzaubern.

Es ist für diese Frage völlig gleichgültig, seit wann, wer, was, wo, wie bei QuantumStep macht.

Für diese Frage ist es wirklich gleichgültig. Du hattest es aber in den Kontext gestellt, dass wir dafür alle keine Erfahrung haben wie man UIs für Telefone gestaltet...

-- hns

Diese Diskussion ist total bekloppt. Daher misch ich mich auch mal ein

Der einzige Grund dafür, dass es kein angepasstes AppKit gibt sondern ein neues UIKit ist: Das UIKit ist komplett leichtgewichtig ohne Altlasten von AppKit. Fertig. Auch wenn das iPhone nen kleiner Mac ist, ist es doch begrenzt an Resourcen. Also macht es durchaus Sinn dafür nen eigenen UI-Layer zu entwickeln.

Außerdem: stell dir vor, du hast einen AppKit, der voller spaghetti Code ist. Was würdest du da bei solch einem Projekt lieber machen: den weiter aufbohren oder nach den neuen Anforderungen was neues bauen? Ich wäre auch den 2. Weg gegangen...

Just my 2ct,
Christian

Nein, ich hatte in den Kontext gesetzt dass wir alle keine Erfahrung mit der Entscheidungsfindung und den Interna des IpHones haben.

Ich sehe es auch völlig anders, weil es völlig anders ist. Die Funktioni von Fenstern im Appkit ist vor allem:

a) Z-Ordering pp.
b) Event-Dispatching
c) Verwalten von Fenstereementen (Closer usw.)

a) ist völlig sinnfrei geworden. Das Z-Ordering ist allenfalls noch ein Index. Da gibt es nicht teilweise verdeckte Bereiche und derlei Kram. Window Levels dürften auch überflüssig sein.

b) funktioniert ebenfalls anders, wie bereits Manfred ausführte.

Bleibt c) übrig, was aber auch ein typisches View macht. Daher passt die Design-Entscheidung, dass Fenster bei CT etwas anderes als bei AK sind sehr wohl. Sie sind etwas anderes, weil sie eine andere Aufgabe haben.

Und das ist wesentlich natürlicher als "Wir haben schon Fenster, die zwar etwas anderes tun, die befrickeln wir jetzt aber so lange, bis es passt." Was nicht passt, wird passend gemacht?

Klar, man kann mir Schraubenziehen Nägel einschlagen. Aber sollte man das tun?

Original von hns
Ich komme mir halt so vor wie der Taxi-Chauffeur der seinen Kunden ein völlig neues Erlebnis bieten wollte indem er zweisitzige Cabrios hat. Und dafür war es anscheinend notwendig Gas- und Bremspedal zu vertauschen...

Ja, kann ich verstehen - das ist in der Tat ärgerlich, wenn es keinen sinnvollen Grund gibt. Andererseits würde ich es auch nicht verstehen, wenn der Autohersteller noch ein Kupplungspedal einbaut, obwohl das Taxi mittlerweile mit E-Motor und Automatik fährt, nur weil Taxifahrer das so gewohnt sind. Durch derartigen Quatsch haben wir jetzt QWERTY und einen auf dem Kopf stehenden Zahlenblock. Und deshalb sind die Hilfsraketen des Space Shuttle etwas schmaler als zwei Pferdehintern...