Hallo!

Angeregt durch die große Diskussionen in den News-Kommentaren zu "Mac OS X Lion erschient Ende Juli?" möchte ich hier einen regen Austausch ermöglichen.

Ich denke, keiner möchte ein Betriebssystem mit x-neuen Features sondern ein Betriebssystem, das möglichst mal fehlerfrei wird.

Die größten Kritikpunkte an Apple sind momentan:

- Grafiktreiber
- OpenGl
- SMB (Kommunikation mit Windows-basierten PCs)
- diverse Bugs in den Applikationen

bitte weitere Kritikpunkte hier mal aufschreiben.

:EDIT:

Als Ergänzung hier diesen Faden:


sowie das Interview mit Dr. Marcel Bresink:


Ich finde, dort bringt er die wesentlichsten Sachen auf den Punkt.


Könnt ihr euch diesen Punkten anschließen?


MfG

also um es klar zu sagen:
weil es unter windows inkosistent ist, soll apple es bitte auch falsch machen.
dann bitte aber auch fenster schliessen mit Alt-F4 fordern. oder programm schliessen? und apple, biete unbedingt das @ woandershin legen! und auf registry will ich auch nicht verzichten...
oh mann.
wie waere es denn so:
apple baut die funktion korrekt, d.h. anders als unter windows ein. d.h. auch anderes tastaturkuerzel.
und leute wie du, die unbedingt im finder eine andere tastaturbelegung wollen als systemweit, die definieren einfach CMD-X im Finder um.

eben: sofort! ist zwar konsistent aber nicht gewuenscht denke ich.


aha, weil apple schon an vielen stellen scheiss macht, muss man auch noch ohne zwingenden grund fordern, den haufen zu vergoessern?
dann doch besser die funktion sauber einbauen und ewige win-user belegen sich ihre tastaturkuerzel um.

Was schrieb ich denn eben? Apple sollte diese Funktion überhaupt einbauen! Wie sie dann benannt wird und welches Tastaturkürzel dann damit verbunden wird, ist dann wohl eher zweitrangig! Unter anderen Betriebssystemen heißt sie dann meinetwegen weiterhin "Cut & Paste" und wird mit Control-X und Control-V bewerkstelligt, und auf dem Mac heißt sie dann meinetwegen "Wegnehmen" und "Einfügen" und wird meinetwegen mit ⌘⇧X und ⌘V assoziert. Völlig egal. Hauptsache, diese ganz deutlich wohl oft nachgefragte Funktionalität wird überhaupt irgendwie angeboten. Wie das Kind dann letztendlich benannt wird, ist doch wirklich semantisches Geplänkel und das Streiten um des Kaisers Bart.

Genau! Und warum tut Apple das bisher nicht und verzichtet dann lieber gänzlich darauf als sich irgendwas Besseres einfallen zu lassen? Apple ist doch sonst um keine Idee verlegen...

sierkb
ja so waere es ok und gegen den einbau einer solchen funktion hat hier auch nie irgenjemand etwas geschrieben!

nur eben request und aehnliche fordern eben nicht nur die funktion sondern vor allem und scheinbar am wichtigsten doch semantisches geplaenkel, inkosistenz und vergroessern des haufens. als naechstes kommt von denen die forderung nach alt-f4, cmd-b fuer beenden und screen-knopf fuer bildschirmfoto.

Wie gesagt ein im Finder intergriertes folder merging wäre jetzt echt mal an der Zeit...
Bei komplexen Ordnerstrukturen ist der Finder nicht zu gebrauchen.

Bedeutet dies, das so ein Tool wie das weiter oben erwähnte Programm TotalFinder sich also nicht konform zu den von Ihnen erwähnten OS X - Funktion verhält, die Entwickler solcher Tool also "tricksen"?

Nun, es ist wohl kein großer Trick dahinter, wenn man eine Funktion "Ausgewählte Objekte für zukünftige Operation markieren" programmiert und sie dann auf den Menüpunkt "Bearbeiten > Ausschneiden" legt.

Bei wirklich benutzerfreundlichen, durchdachten Desktop-Programmen sieht das „Ausschneiden“, wie ihr euch das vorstellt, so aus, wie im Bild.
Stünde doch auch dem Finder gut, oder? (Ganz zu schweigen von Windows).

Die Ausschneiden-Funktion war in den frühen Betaversionen von OSX bereits realisiert worden und wurde nachträglich bewusst von Apple (nur für den Finder) deaktiviert, weil die Funktion nicht fehlerfrei war und es in seltenen Fällen zu Datenverlusten kam. Apple hat die Funktion später nicht nachgereicht, weil es zu tiefe Eingriffe in die Systemarchitektur erfordert hätte um sie fehlerfrei zu implementieren.
(Aus diesem Grunde ist auch heute noch möglich, auf Kommandozeilenebene die Ausschneiden-Funktion im Finder zu aktivieren, allerdings auf eigenes Risiko)

Fakt ist, dass OSX ein in vielen Bereichen sehr ausgeklügeltes System ist, das gerade auch im Detail überzeugen kann und großen Wert auf Konsistenz und Usability legt.
Der Finder ist jedoch eine Schwachstelle im System, wer auch mit anderen Betriebssytemen arbeitet weiß dass das Dateimanagement in OSX umständlich ist und somit eigentlich Apples Philosophie des einfachen Zugangs und der Benutzerfreundlichkeit widerspricht.

Nachdem dieser Thread von Vandalen für kindische ideologische Grabenkämpfe missbraucht wurde, würde ich mich freuen, wenn in zukünftigen Posts wieder mögliche neue Features von Lion besprochen würden. Ich hoffe das klappt ohne das gleich wieder Leute anfangen zu weinen wenn jemand auch mal etwas an OSX verbesserungswürdig findet.

Ich würde mir in 10.7 Lion einen neuen Finder mit folgenden neuen Funktionen wünschen:
- Cut Funktion (sierkbs Vorschlag klingt einleuchtend und leicht umsetzbar, auch wenn es einige Puristen als "workaround" ansehen, mir ist die Funktion wichtig - egal wie technisch umgesetzt)
- Folder Merging (bereits in den 90ern state-of-the-art)
- eine Tab-Funktion im Finder wie in Browsern wäre sehr schön
- der Dateipfad sollte standardmäßig im Finder angezeigt werden (Übersichtlichkeit)
- ich finde die 2-Spalten Ansicht im Pathfinder auch sehr nützlich
Ich würde es ja generell begrüßen wenn Apple einfach mal eine Ecke von den 50Mrd Barreserven locker machen würde und die Firma, die Pathfinder entwickelt hat, aufkaufen würde. Zack ins System integrieren, fertig. Wenn Apple glaubt, dass die Funktionen bereits zu "kompliziert" für den Normal-User sind, könnten sie eine "einfache" und eine "pro" Ansicht für den Finder einbauen die man auf Knopfdruck umschalten kann.

Ich muss gestehen, ein wenig Angst vor diesem Launchpad habe auch ich. Es erscheint noch recht fremd. Haha dennoch werde ich es mir gründlich anschauen, man muss ja auch offen für neues sein! Und irgendwo bin ich auch neugierig.

Aber wie auch oben schon angesprochen:
Evtl. können einige nicht nachvollziehen wie sehr man an Konsistenz hängen kann. Vor allem im bereich GUI hat Apple leider schonmal sich ein wenig verzettelt (Tiger und Pre- anyone? Brushed Alu, Cocoa, Aqua und wie es alles hieß Fenster Designs etc, für die, dies nicht wissen).
Und langsam bekomme ich den Eindruck, dass Apple wieder damit anfängt.Transparente Menüleiste(man erinnere sich bei apple war transparent immer ein zeichen für temporäre dinge... und was ist konstanter als die menüleiste?) // Schwarze leisten bei Quicktime, ständig wechselnde Grauverläufe bei itunes, von den buttons will ich gar nicht erst anfangen. Komische Positionierung wiederum der buttons beim App-Store (interessanterweise ähnlich wie bei Flash CS5). Und und und...

Ich wünsche mir, das diese Klarheit, die mit Leopard eingeführt nicht wieder verschwindet.


PS: Irgendjemand hatte vorher noch was zu versteckten Dateien erwähnt. Zumindest bei versteckten Ordnern besteht die möglichkeit (wenn man ihren namen kennt) im finder über apfel - shift - g zu navigieren ohne ein terminal fenster öffnen zu müssen.

PPS: apfel + click auf symbol von Finderfenstern zeigt einen quasi auch den pfad an, oder wenn man dieses symbol dragged, wird der pfad kopiert.

Sagt. mal, verschiebt ihr den ganzen Tag nur Dateien, oder warum wollt ihr unbedingt so ein Quatsch, wie "Folder merging"? Am Ende sollen sogar "Dokument" und "dokument" zwei verschiedene Dateien sein. Der absolute Benutzer-GAU.

mit anderen Worten: ihr wollt also, daß Apple bewußt die Fehler von M$ übernimmt und damit ein inkonsistentes System erstellt?

Ähm, hallo?!

Beispiel: Ich habe eine App, das hat eine Ordner-Struktur. Ich habe weiterhin eine Zip-Datei mit Lokalisierungs-Dateien drin für diese App. Nun will ich den Inhalt dieser Zip-Datei, also die Lokalisierungsdateien (z.B. für die Sprache Deutsch) gerne in die Ordner-Struktur der App einpflegen, also mergen, OHNE dass das Kopieren mir die ursprüngliche Ordnerstruktur der App zerstört. Kann ich über den Finder, so wie er bisher ist, nicht bewerkstelligen. Weil der bei so einer Aktion die ursprüngliche Ordner-Struktur und die ursprünglich darin enthaltenen Daten gnadenlos mit der neuen Ordner-Struktur und dessen Daten überschreibt bzw. ersetzt, anstatt beide miteinander zu mischen.

Und derer Beispiele aus dem Alltag gäbe es einige zu nennen.

Ausgerechnet das ist ein problematisches Beispiel. Damit wird es aber gleichzeitig zum guten Beispiel, denn man kann daran erkennen, in welchem Dilemma sich Apple bei der Finder-Entwicklung befindet.

Gemäß der Macintosh-Logik ist eine App eine App und eben kein Ordner. Apple unterscheidet zwischen Ordnern, die als Ordner dargestellt werden und Ordnern, die als Einzelobjekt und damit eben nicht als Ordner behandelt werden dürfen. Die heißen dann "Pakete" (Bundles). Eine App ist immer ein Paket.

In dem Beispiel schilderst Du einen Arbeitsablauf, wie er bei Entwicklern tatsächlich andauernd auftritt. Ein "normaler" Benutzer würde aber eine ganz andere Reaktion des Finders erwarten. Beispiel: Du mischst zwei Ordner, die Apps enthalten. In dem einen Ordner befindet sich zufällig Version 3 einer App, in dem anderen zufällig Version 5 genau der gleichen App.

Würde der Finder nach Deinem Prinzip vorgehen, würden sich die Pakete der beiden App-Versionen mischen. Damit wäre die App aber zerstört. Nicht nur, dass ein Versionswirrwarr entstehen kann, auch die digitale Versiegelung der App wird gebrochen, so dass die App möglicherweise nicht mehr startet. Man könnte noch weiter ausholen und Sonderfälle konstruieren, in denen es ein Angreifer über das Gleichnamigmachen von Paketen schafft, durch dieses Merge-Verhalten SUID-Root-Komponenten in bestehenden Programmen auszutauschen und somit Sicherheitslücken im System zu öffnen.

Mit anderen Worten: In diesem Beispiel bei einem "normalen" Benutzer darf der Finder Pakete nicht als Ordner behandeln, sondern muss sie als atomare Objekte ansehen und komplett gegeneinander ersetzen, also bei gleichen Namen nicht mischen. Im obigen Fall bei einem Entwickler muss er jedoch genau das Gegenteil tun.

Das ist der Hauptgrund, weshalb Ordnermischen in Mac OS X ein offenes Problem ist. Man könnte das nur lösen, indem man z.B. einen "Profi-Modus" in den Finder einführt, in dem er komplett anders arbeitet, insbesondere auch bezüglich unsichtbaren Objekten. Würde ich mir auch wünschen.

dom_beta, wenn ich mal im Internet mal so querlese über die Historie von Copy & Cut & Paste bzw. über die systemweite Etablierung von ⌘X, ⌘C und ⌘V, dann war es die Firma Apple, die dies mit als Erstes etabliert hatte (und mit dieser Tastatur-Kombination in Zusammenhang brachte) in Lisa und den ersten Macintoshs (nachdem man es sich bei den Xerox-Maschinen abgeschaut hatte), und das hat sich dann über alle Systemgrenzen hinweg seit den 80er Jahren auf andere Systeme übertragen und bis heute gehalten.

Apple würde damit also keine Fehler von M$ übernehmen, sondern sich selbst und seiner Linie eigentlich nur treu bleiben. Zumal es Dir zum wiederholten Male anempfohlen ist, anzuerkennen, dass es auch noch andere Systeme gibt als nur Windows und Macs, und dass es da auch einen großen Unix-Bereich gibt, wo es auch Copy & Cut & Paste gibt. Sowohl für Text als auch für Dateien. Es ist völlig wurscht, wie das Kind dem Nutzer gegenüber benannt ist, Hauptsache, die Funktion steht überhaupt zur Verfügung!

Meinetwegen kann MacOSX unter der Haube, wenn nicht Text mit ⌘X markiert wird, sondern eine Datei, diese Datei nicht ins Clipboard schieben, sondern, wie Marcel Bresink es gesagt hat, "für weitere Operationen vormerken". Solange verbleibt die Datei an dem Ort, wo sie ist. Und erst, wenn der Benutzer an einer Stelle im Dateibaum sagt "Hier soll sie bitte hin, die Datei!", ausgedrückt durch ⌘V (also "Einfügen", wie ein kleines Kind "Ga" sagen), dass MacOSX dann tätig wird und diese Datei, von der jetzt der Ursprungsort bekannt ist und auch der Zielort bekannt ist, dass diese Datei dann ganz einfach dorthin verschoben wird. Auf Shell-Ebene macht man so einen Vorgang unter Unix mit dem Move-Befehl mv (Syntax siehe Manpage zu mv).

Eine solch markierte Datei würde dann nicht im Clipboard gespeichert, nirgendwo sonst in keinem temporärem Verzeichnis, würde keinen unnötigen Platz verbrauchen, auch 1TB große Dateien könnten auf diese Weise von A nach B verschoben werden (auf Dateisystemebene ist das Ganze im Grunde nur eine Inode-Änderung). Und diese datei wird am Ursprungsort erst dann gelöscht, wenn sie vollständig und heil am Zielort angekommen ist, dafür sorgt unter der Haube schon das Betriebssystem bzw. konkret die Selbstorganisation des Dateisystems selber, der mv-Befehl auf Unix-Ebene ist diesbzgl. ja auch abgesichert. Und wenn ein solcher Vorgang unterbrochen, abgebrochen wird oder vom Benutzer eine andere Datei angewählt würde, würde die zuerst ausgewählte Datei ebenfalls am Ursprungsort verbleiben, und der ganze Vorgang würde sich dann bzgl. der neu angewählten Datei abspielen.

Anstatt z.B. diesen Weg zu gehen, bietet Apple dann lieber gar nix an. Auf Unix-Ebene geht's doch auch, das Verschieben von Dateien ohne Maus!

Und wie gesagt: wie das Kind nachher am Ende heißt und für den Benutzer sichtbar ist, ob nun "Ausschneiden" & "Einfügen" oder "Für Verschiebung vormerken" & "Einfügen", ist doch nun wirklich völlig unerheblich und zweitrangig. Dann wird's halt anders genannt, wenn der Begriff "Ausschneiden" von der Semantik her schon belegt ist und nur für text zu gelten hat. Wichtig ist doch, dass die Funktionalität an und für sich bereitgestellt ist! Und das ist sie in Apples Finder eben leider nicht oder nur für die Maus. Und eine Tastatur-Entsprechung existiert da nicht, obwohl die Liste von Tastaturkürzeln und Tastatur-Operationen beim Mac ja ziemlich lang und ausführlich ist! Für alles Mögliche, für alle möglichen Situationen gibt es auf dem Mac jeweils ein Tastaturkürzel bzw. Kurzbefehle. Nur ausgerechnet für diese eine Operation, die betriebssystemübergreifend bei allen Betriebssystemen durchaus recht häufig gebraucht und nachgefragt wird (also nicht nur unter Windows, sondern auch unter unixoiden Systemen und eben auch auf dem Mac), da gibt es keine Möglichkeit, diese eine Operation, die einem gerade bei etwas größeren und verschachtelten Dateibäumen eine echte Hilfe und Unterstützung ist, auch per Tastatur zu bewerkstelligen. Stattdessen muss man sich beim Mac per Maus und aufspringenden Ordnern mühsam zum Ziel durchhangeln mit dem Risiko, dass man sich da auf diesem Weg ggf. auch mal vertut und die angefasste Datei an der falschen Stelle in den falschen Ordner fallenlässt, während das direkte Anwählen per ⌘X (oder meinetwegen ⌘⇧X) und gezielte Fallenlassen per "Einfügen" an der vorher in Ruhe ausgewählten Stelle dem Nutzer eine viel größere Zielsicherheit anbietet und ein solcher Vorgang in der Regel auch viel schneller zu bewerkstelligen ist als ein mühsames per aufspringenden Ordnern stattfindendes Durchhangeln bis zum Zielort.

In diesem Punkt ist der Mac einfach deutlich umständlicher zu bedienen als andere Systeme und bietet eine viel größere Angriffsfläche für Entscheidungsfehler seitens des Benutzers beim mühsamen Durchhangeln durch eine Ordner-Struktur, die ggf. auch mal etwas tiefer verschachtelt ist. Wie oft bin ich schon während des Durchhangelns in Ordnern gelandet, wo ich eigentlich nicht hin wollte und musste dann zurückgehen und das Ganze nochmal von vorne anfangen, um dann erst im 2. Anlauf meinen Zielordner zu finden.

Schneller geht es da sicherlich, wenn man im Finder den Quellordner offenhat, sich in Ruhe den Zielordner aufmacht oder per Finder-Menü "Gehe zum Ordner..." direkt anwählt und dann die betreffende Datei oder Dateien in Ruhe markiert (wie auch immer man das dann benennt), den Maus-Fokus auf den Zielordner lenkt und dort die betreffenden Dateien per "Einfügen"-Tastaturkommando (wie auch immer man das dann benennt) einfach dort hinverfrachten/hinverschieben lässt.

Mir fiel da jetzt adhoc dieses Beispiel ein, weil es mir ab und zu mal begegnet. Ich könnte aber auch ein anderes Beispiel nennen, zum Beispiel die Lokalisierung eines lokal installierten CMS-Systems, das als Tarball daherkommt (standardmäßig mit allen Sprachdateien in englischer Sprache) mit getrennten Lokalisierungs-Dateien, die ebenfalls als Tarball oder Zip-Dateien daherkommen und man diese beiden miteinander verheiraten und mergen muss bzw. will. Oder ein Nightly-Build eines Browsers, den man gerne auf deutsch hätte. Oder ein Dev-Build von OpenOffice oder Eclipse, das man gerne auf deutsch hätte und es da getrennte Sprach-Dateien gibt. Oder, oder, oder. Oder Plugins für ein CMS oder ein anderes Programm. Etc. pp.

Das sind nicht nur für einen Entwickler regelmäßig auftretende Situationen, sondern die können durchaus auch mal bei einem Joe Average User auftreten.

X-Jo
Danke für das jinnee-Beispiel! Die Funktion "Sammeln & Einsetzen" (Collect & Paste) ist genau das, wir alle wollen und es gibt keinen Konflikt mit den Funktionen Cut oder Copy.

Nein eben nicht. Schade, dass Du offenbar den ganzen Sinn der bisherigen Diskussion nicht verstanden hast. So viel Text für nichts.

Marcel Bresink:

Stichwort "normaler" Benutzer:

Dieser "normale" Benutzer arbeitet an mehreren Texten, hat sich eine Ordner-Struktur angelegt. Er arbeitet nicht alleine, sondern jemand der woanders wohnt, arbeitet auch an diesem Werk. Man schickt sich gegenseitig Änderungen zu, bzw. der Eine arbeitet an dem einen Text, der Andere arbeitet im Dateibaum an einem anderen Text. beide wollen/müssen ihre Texte jeweils zusammenbringen und verschmelzen. Beide wollen/müssen ihren Text jeweils in den Dateibaum des Anderen einpflegen. Beide tauschen ihre Dateien miteinander aus, sie sind abgespeichert in einer Zip-Datei inklusive vorher verabredeter gemeinsamer Ordner-Struktur. Der Windows- oder Unix/Linux-Benutzer kann den Inhalt dieses Zips schnurstracks in seinen dateibaum einpflegen: Entpacken, rüberziehen in seinen Wurzel-Ordner seine Projekts, die beiden Datei-Strukturen werden miteinander gemischt, Gleiches bleibt erhalten, Neues wird hinzugefügt. Fertig.
Der Mac-Anwender hat jetzt ein Problem. Weil der Finder nicht mergen kann. Ihm steht eine etwas umständlichere Prozedur bevor, wenn er seine eigenen bisherigen Dateien erhalten will und nur die Änderungen bzw. die neuen Dateien des Anderen in seinen Dateibaum an der richtigen Stelle einpflegen will.

Marcel, ich trenne zwischen Funktionalität und nach außen hin für den Nutzer sichtbarer Benennung/Bezeichnung dieser Funktionalität. Es ist möglich, beides unter einen Hut zu bringen ohne dass es sich widerspricht. Das geht ganz sicher.

+1

Genau das meine ich auch. Wir beide widersprechen uns da überhaupt nicht sondern sind einer Meinung, Marcel!

Nein, die Funktion mit der Bezeichnung "Cut" hat auf dem Mac seit Anbeginn eine feststehende Bedeutung, die sich niemals verändert hat. Anders, als Du es andeutest, erlaubt es der Mac prinzipiell übrigens "Alles" auszuschneiden, nicht nur Text. Und das geht auch für Bildausschnitte, Tonausschnitte, Farben, Schriftarten, Dateilisten, usw. sofern es das jeweilige Programm anbietet.

Die Funktionalität, die Du beschreibst, hat mit diesem Cut jedoch nichts zu tun. Sie entspricht dem, was man dank X-Jos hilfreichem Beispiel gut als "Collect" bezeichnen könnte. Eine solche Collect-Operation fehlt im Finder und wird dringend benötigt. Darüber waren sich alle einig. Nicht einig war man sich nur darüber, ob man das Collect nicht fälschlicherweise mit dem Menüpunkt Cut beschriften könnte, um das bequeme Tastenkürzel mit dem X zweckentfremden zu können.

Die von Apple vertretene Meinung ist, dass man sich diese bewusste Fehlbeschriftung nicht leisten kann. Die ganze Diskussion drehte sich daher ausschließlich um die Benennung und das daraus resultierende Tastenkürzel. Alles andere war völlig unstrittig.

Falls Du es noch nicht bemerkt haben solltest, ich bin gedanklich schon längst weg von diesem feststehenden Begriff "Cut"...

Ich war mir trotz Nachlesens und Recherche im Web bzgl. der in die 70er/80er Jahre zurückreichenden Historie nicht ganz sicher, also habe ich es, historisch gesehen, erstmal auf Nur-Text beschränkt. Wenn eine solche Beschränkung wie Du sagst noch nie existierte, und auch Datei-Operationen schon immer davon betroffen waren, dann eigentlich umso schlimmer, dass Apple hier für diese eine (doch wohl im Alltag recht häufig nachgefragte) Operation, die wir hier diskutieren, keine Funktionalität/Entsprechung per Tastatur anbietet.

Siehe erster Satz dieses Beitrags: ich bin gedanklich schon längst weg von dem "Cut"-Begriff. Ich dachte, das könnte man aus meinen Beiträgen auch so herauslesen. Offenbar habe ich mich in dieser Annahme da wohl geirrt. Deshalb nochmal extra für Dich: wir beide sind da näher zusammen bei der ganzen Diskussion als Du bislang denkst. Von einem nur im Zusammenhang mit Texten semantisch zutreffenden bzw. sinngebenden Begriff "Cut" (oder zu deutsch: "Ausschneiden") bin ich schon lange gedanklich weg.

Ja!

Dann halt anders benannt. Und dann meinetwegen nicht mit ⌘X, sondern meinetwegen mit ⌘⇧X assoziiert. Oder mit einem völlig anderen Tastaturkürzel. Ist wurscht und zweitrangig, da ließe sich sicher was Pasendes und Sinnvolles finden. Wichtiger ist das Angebot der Funktionalität an sich. Dass sie überhaupt da ist, dass sie überhaupt genutzt werden kann. Und dann erst kommt für mich die Frage, wie man sie am Schlauesten und Sinnvollsten benennt und ihr ein sinnvolles Tastatur-Kürzel zuordnet.

Und weil Apple da bisher keine sinnvolle Benennung gefunden hat und kein sinnvolles Tastaturkürzel, hat Apple sich dazu entschieden, diese Funktionalität per Tastatur gar nicht erst anzubieten? Ist das offiziell verbürgt, dass das Weglassen aus diesem Grund eine offizielle Entscheidung seitens Apple ist? Oder ist das Deine Privatmeinung bzw. Deine private Vermutung dass dem so sei oder gewesen sein könnte (Konjunktiv)?

Sorry, das ist doch keine Situation aus dem Anwender-Alltag. Das ist ein Spezial-Fall. Außerdem würde es ohnehin nicht direkt gehen, da es sich ja um Pakete handelt, die man auf gesonderte Art öffnen muß, um deren Inhalt zu sehen.

Wenn Du den ganzen Tag nichts anderes machen mußt, dann gibt es doch sicher ein Werkzeug dafür. Ich versuche ja auch nicht dauernd mit einem Schlitzschraubendreher Spaxe reinzudrehen ...

Der Jinnee hatte damals Funktionen, die ich heute noch vermisse, und den Finder alt aussehen lassen:

- Fenster wurden nur so groß geöffnet, wie deren Inhalt war.
- Fenster wurden beim Öffnen intelligent nebeneinander angeordnet, nicht wie sonst üblich übereinander Exposé (fast) überflüssig.
- Fenster konnten mit Klick auf die Pin-Nadel festgepinnt werden und öffneten sich dann immer in dieser Größe und Darstellung. Lies sich genau so wieder abschalten dies ist viel intuitiver und leichter nachvollziehbar, als das Verhalten beim Finder.
- Fenster konnten abhängig vom Inhalt unterschiedlich dargestellt werden: viele Objekte - Listendarstellung, wenige Objekte - Symboldarstellung. Die Grenze war frei wählbar.

Und, und, und ... :'(

das hat bisher niemand behauptet! warum apple das bisher nicht eingebaut hat, weiss keiner! und es hat auch niemand behauptet, das zu wissen, geschweige denn, dass das schlecht waere, wenn sie so etwas einbauen wuerden!
man weiss nur, warum sie es nicht mit der menüfunktion "objekt sofort entfernen und in die zwischenablage legen"="cut" gemacht haben. weil es eben nicht gewuenscht ist, das die datei sofort entfernt wird.

richtig und von niemandem bestritten.
es gibt hier nur einige ewige win-user, die auch damit nicht zufrieden sind und nicht nur mit recht die funktionalitaet fordern, sondern eben auch, dass man den falschen menuepunkt und tastaturkuerzel nimmt. wenn eine solche funktion mal integriert ist, koennten die ja sich selber ein unsinnig falsches kuerzel einstellen. aber das reicht ihnen ja nicht...

Du hast oben gelesen, dass Marcel Bresink das nach empfinden kann, was ich schriebb bzw. dass ihm das wohl auch schon häufiger gefehlt hat. Zumindest für uns beide kommt es häufiger vor.

Ich habe oben ein weitere Beispiel genannt. Da lassen sich sicher noch einige weitere Beispiele nennen. Oder willst Du damit sagen, dass der Anwender-Allag nur so definiert ist, solange und wie er in Deine und Apples Weltsicht passt?

Fionda:

Wenn Du richtig gelesen hast, habe ich das auch nicht behauptet oder behaupten wollen, ich habe das an Marcel Bresink als Frage formuliert. Als echte Frage.

Dass einigen Mac-Usern anscheinend nie begreiflich sein wird, dass es auch noch andere Systeme außer Mac und Windows gibt...
Nicht jeder, dem was am Mac fehlt oder der Kritik am Mac übt, kommt aus der Windows-Welt oder ist damit gleich ein Freund und Anhänger von Windows! Es gibt zwischen Scharz und Weiß auch noch Grautöne. Und Farben gibt es auch noch! Es gibt auch noch Nutzer, die haben sich mit anderen Betriebssystemen außer Mac und Windows beschäftigt und nutzen seit Jahren zum Beispiel irgendein Unix bzw. Linux und haben Erlebnisse und Erfahrungen unter X-Window gemacht bzw. GNOME, KDE, Windowmaker (der GUI zu GNUStep), Enlightenment, XFCE, fvwm oder sonst einem X-Window-basierten Fenster-Manager oder Desktop Environment gemacht.

Umgekehrt müsste man eher sagen, dass es unter heutigen Mac-Anwendern ein paar Ewiggestrige zu geben scheint bzw. tatsächlich auch gibt, die gedanklich noch in der Vor-MacOSX-Zeit hängengeblieben sind und nicht oder nur schlecht wahrhaben können, dass sich seitdem NeXTStep und MacOS zu MacOSX verschmolzen worden sind, da auf ihrer Plattform teilweise einige Dinge grundlegend geändert haben bzw. neu hinzugekommen sind, die vorher nicht da waren bedingt durch den Unix-Unterbau und dessen Besonderheiten und dessen Mächtigkeit und Vielfalt bzw. dessen Möglichkeiten.
Einige Ewiggestrige scheinen diese neuen, zusätzlichen Möglichkeiten, die der Unix-Unterbau mit sich bringt, ja schon fast als Bedrohung auf, anstatt sie als unschätzbaren Vorteil und Chance und Mehrwert zu begreifen.

Sry Folder Merging ist ein wichtiger Faktor... Viele Projekte werden an mehreren Rechnern bearbeitet.In meinen Fall (Audio) haben diese oft eine sehr komplexe Ordnerstruktur.Jedes mal muss ich zig Ordner und Dateien manuell verschieben, weil MacOsx kein Merging kann...und ja Windows kann das...

ich habe vermutlich schon mit mehr unterschiedlichen system gearbeitet als du denkst. alleine an unixen waren das mehr als drei ohne ein apple-system zu berücksichtigen...
in diesem speziellen fall geht es aber eben doch um windows, denn soweit ich weiss stammt der missbrauch der funktion "objekt sofort entfernen und in die zwischenablage legen" durch eine völlig andere funktion aus der windowswelt. gerade wegen solcher leute wurde das teilweise auch auf andere systeme uebernommen.

eben und marcel hatte schon erfolglos darauf hingewiesen, dass fuer die gewuenschte funktion unter next bereits eine noch bessere moeglichkeit drin war, die es leider nicht in os x geschafft hat.

ja, sehe ich genauso. sieht man ja an diesem thread und den unsinnigen forderungen. mich kannst du damit ja nicht meinen.

Meint ihr man wird noch ROSETTA nachinstallieren können in Lion?
Wird schon irgendwie noch dabei sein, oder?

also, solche Funktionen wie Mission Control etc. empfinde ich als Spielerei.

Viel wichtiger wäre die Frage, ob Apple endlich Fehler beseitigt hat oder nicht.

Ebenso interessant finde ich die Frage wie gut es sein wird, wenn es keine seperate Serverversion mehr gibt.

vorallem, was soll das heißen?:


heißt das, daß ich wenn ich mit den Fingern auf den Trackpad nach unten wische der Mac dies als nach oben interpretiert?

Es ist doch sicher einfach möglich festzustellen ob man sich grad in einem Bundle befindet oder nicht? Von dem her sollte das nicht das Problem sein (gibt da ja ne vordefinierte Ordnerstruktur)

ad Sicherheitslücken:
Dein Beispiel bekommt überhaupt keine Mehr-Bedeutung im Fall des Merge-Verhaltens. Wenn das Problem auftaucht, dann ist es jetz ebenfalls schon der Fall! Weil Dateien einzeln in Bundels austauschen kann man jezt auch (ist nur umständlicher). Ausserdem falls das Programm auf administrative Komponenten zugreifen will braucht es immer noch das Admin Kennwort bzw. man braucht das Passwort vielleicht auch schon beim Ändern des Bundles (wenn es in bestimmten Ordner liegt).

iOSig
der inhalt wird durch den finger gezogen, nicht der scrollbalken. lässt sich wieder umschalten in den prefs.

Offenbar hast Du das Problem nicht verstanden. Es geht hier um den Effekt, dass der Finder ein und dieselben Ordnerstrukturen komplett unterschiedlich behandeln muss, je nach dem, ob der Benutzer gerade als Entwickler arbeitet oder als "normaler" Anwender. Der Entwickler erwartet, dass die Bundles beim Merge als Ordner behandelt (also ignoriert) werden, der Anwender erwartet, dass die Bundles beim Merge als atomare Datei behandelt werden.

Bed_Moat

Immer noch am Lamentieren, obwohl…

hoffentlich weiß Apple und die Samba-Leute dies auch was du weißt, also wo sich die Spezifikationen befinden

Zum Thema ausschneiden im Finder:

Manchmal habe ich das Gefühl, die Menschheit ist irgendwann zu faul sich noch auf die Toilette zu bewegen.

Ich verschiebe auch viel auf ne externe Platte, grade vom Desktop, und wenn's dann weg muss ist es ne halbe Sekunde später mit der klitzekleinen Bewegung meines Finger auf dem Trackpad im Papierkorb.

Die Probleme mancher möchte ich haben.

jupp.

Die technische Basis hingegen sollte man beachten: stabil, schnell, fehlertolerant,

Tab_Dome


                                        fehlertolerant wirklich

Mein Post vorhin war nicht auf die Entwickler bezogen, sondern auf das angebliche Sicherheitsproblem dass du da ausgemacht hast mit dem ersetzen von Komponenten in einem Bundle.

Aber nun zu diesem hier:
Entwickler wissen ja genau, dass das Bundle ein Paket ist, folglich werden die wohl von der Funktion "paketinhalt anzeigen" Gebrauch machen und das dann reinkopieren als ob nix gewesen wäre.
Wer das nicht so macht, ersetzt halt die App einfach. Dann wäre das Problem mit der Versionsvermischerei gelöst oder?
Oder bei der obligatorischen Nachfrage ob dateien ersetzt oder beibehalten werden sollten, könnte es auch einfach eine Auswahlmöglichkeit geben ("Merge + Bundels ersetzen, Merge + Bundels mergen; vllt ja auch mit einer zusätzlichen taste beim einfügen/menüpunkt).

Aber warum sollen Ordner ignoriert werden? Wenn die Merge Funktion komplett ist, dann sollte das auch über mehrere Ebenen tief funktionieren. Oder meinst du damit dass sie ersetzt werden sollen?

verwechsel das nicht mit "fehlerbehaftet"!

manche Programme sind so nervös, wenn dort irgendeine Einstellung nicht 100%ig richtig ist, klappt das ganze System zusammen.

Wenn ein normaler Benutzer durch einen Kopiervorgang ein Programm überschreibt, das sich in einem für diesen Benutzer schreibgeschützten Ordner befindet, sodass der Finder per Administrator-Berechtigung root-Rechte anfordern muss, und gleichzeitig dabei ein Merge-Vorgang stattfinden würde, wie er oben skizziert wurde, dann ist dem Benutzer nicht klar, dass hierbei als Nebenwirkung SUID-Komponenten in das Programm geschleust werden könnten, die dann eine eventuell ungeklärte Ausführungsberechtigung haben. Das ist ein Sicherheitsproblem.

Auch das ist zu kurz gedacht. Bundles enthalten oft mehrfach verschachtelte Unter-Bundles und jedes dieser Bundles kann Sprach-Ressourcen enthalten. Das ist bei Programmen mit eingebetteten Frameworks und Plug-Ins alltäglich. Sierkb hatte eine Operation im Sinn, bei denen über alle diese Ordnerhierarchien hinweg alle Sprachressourcen aller Bundles in einem Programm korrekt durch einen Merge ergänzt oder aktualisiert werden. Auch das ist eine alltägliche Entwicklersituation. Es reicht dafür bei weitem nicht, lediglich das "oberste" Bundle von Hand zu öffnen. Auch dieser eine manuelle Öffnungsvorgang ist für Entwickler schon extrem lästig, während er für andere Benutzer bereits völlig unverständlich sein kann.

An dieser Stelle der Diskussion ging es nur um den Punkt, dass verschiedene Anwendergruppen bei einer scheinbar einfach aussehenden Drag-Operation völlig verschiedene und widersprüchliche Vorstellungen davon haben können, was diese Operation tatsächlich tun soll.

Aber nicht stellvertretend für das Mergen im Allgemeinen ,das fiel mir nur grad' spontan ein als Beispiel, den Grund, warum mir das spontan und als allererstes einfiel nenne ich gleich...

Und trotzdem wird's gemacht, und trotzdem klappt's. Apple schafft so einen Merge-Vorgang bei seinen Updates, indem ggf. nur bestimmte Dateien eines Bundles beim Update ausgetauscht werden und der ganze Rest des Bundles, seine gesamte Struktur und Rechtevergabe inklusive des Dateizugriffdatums verschiedener unberührter Ordner, bleiben erhalten und unberührt. Wenn derjenige, der da grad' was drüberinstalliert und damit mergt, die Datei- und Verzeichnisstruktur und die innherhalb dieser Struktur vergebenen Rechte genau kennt und er sie beibehält, dann gibt's da i.d.R. keine Probleme. Apple verhaspelt sich da manchmal selber und arbeitet unsauber, indem sie dann nicht gleichzeitig auch die Dateirechte in ihren BOM-Dateien anpassen gegenüber dem, was da grad' auf die Platte geschrieben wurde (oder umgekehrt), weshalb dann ab und zu und leider dann etwas länger ungefixt bleibend, die berühmten Meldungen im Festplattendiesntprogramm auftauchen, wenn man da mal ein "Zugriffsrechte des Volumes reparieren" initiiert, und die dann leider immer wieder kommen, solange Apple diese Diskrepanz zwischen Ist-Zustand und Soll-Zustand nicht einander angleicht und nivelliert.

Um aufzugreifen, worauf ich oben verwiesen habe: OpenOffice.org bietet seine Entwickler-Builds nur englisch-sprachig an. LibreOffice bisher aus mir unverständlichem Grund auch (unverständlich deshalb, weil die fertigen Release-Builds von OpenOffice ja auch komplett in der jeweiligen Landessprache angeboten werden und nicht zweigeteilt als engliche Version + Sprachpaket). Wer's in seiner Landessprache haben will, der muss zusätzlich das Sprachpaket installieren. Das ist von seiner inneren Dateistruktur genau so aufgebaut, wie die Ordner-Struktur der OpenOffice.app das vorgibt. Und diese Landessprachen-Dateien werden vom Installer dieses Sprachpakets dann einfach dort reingemergt, und fertig, eine entsprechende Konfig-Datei wird dahingehend kurz angepasst, dass als erste Wahl nun die Sprache Deutsch präferiert werden soll statt der engl. Sprache und Programmoberfläche und fertig.

Anderes Beispiel bzgl. Mergen von z.B. Plugins für die Blog-Software Movabletype oder Wordpress auf Dateiebene: Ich habe meine Blog-Software (oder CMS) mit vorgegebener Struktur auf der einen Seite, und ich habe ein Plugin in Zip-Form oder als Tarball auf der anderen Seite. Beide möchte ich mit möglichst wenig Aufwand zusammenbringen. In der Zip-Datei oder dem Tarball ist die Datei-und Ordner-Struktur der Blog-Software oder des CMS drin enthalten. Ich extrahiere die Zip-Datei bzw. den Tarball, es ergibt sich ein neuer Ordner mit vorgegebener Datei- und Ordnerstruktur. Und ich möchte diese nun extrahierte Datei- und Ordner-Struktur auf kürzestem Wege in mein vorhandene CMS bzw. die Blogsoftware bringen. Unter Windows, GNOME, KDE etc. kein Problem. Weil die mergen können. Einfach die extrahierte Ordnerstruktur anfassen und auf den obersten Ordner der Blog-Software oder des CMS legen und fertig. Da beide Ordnerstrukturen identisch sind, werden sie deckungsgleich (in der Mathematik spricht man, glaube ich, von "Kongruenz" bei Deckungsgleichheit) aufeinander abgebildet, und nur die neuen Dateien, die vorbei an dieser Deckungsgleichkeit gehen, werden an die Seite der bisherigen Dateien geschrieben, bei Deckungsgleichheit auf Datei-Ebene gibt's eine Nachfrage des Betriebssystems, ob tatsächlich Datei A nun mit der neueren Datei A-Neu überschrieben werden soll bzw. ob das fortan immer und ohne Nachfrage geschehen soll oder ob bei jeder Aktion nun nachgefragt und evtl. auch mal mit Nein geantwortet werden darf.
Und unter MacOSX habe ich bei so einem Vorhaben ein Problem, wenn die dateistruktur etwas komplizierter und stark verschachtelt ist, ein etwas umfänglicheres Problem, denn MacOSX kann nicht mergen, sondern nur überschreiben. Gnadenlos überschreiben. Ohne wenn und aber. Um dem zu entgehen und um das NICHT zu machen, muss ich die neuen Dateien alle von hand anfassen und von Hand an ihren Zielort tragen. Jede einzelne Datei. Jeden einzelnen Eimer Wasser muss ich vom Brunnen in die Küche tragen.

Dass es prinzipiell anders zu machen ist als der Finder es bisher dem normalen Anwender gegenüber zulässt, beweist nicht nur Apple bei seinen System-Updates, sondern das zeigt auch solche Installer-Software wie die von z.B. OpenOffice.org oder Libre-Office bzgl. ihrer Sprachpakete, und auf Shell-Ebene kann's Unix ja auch, wenn man den cp-Befehl entsprechend anwendet. Es geht also prinzipiell, nur der Finder will's nicht können oder darf's nicht können, weil Apple da anscheinend eine bestimmte Ansicht hat, die aber nicht unbedingt und tatsächlich in allen Fällen die tatsächliche Lebenswirklichkeit und Bedürfnisse der Anwender zu 100% trifft, sondern dass Apples Entscheidung hier ein wenig stur ist und eine Situation schafft, die völlig neben dem liegt, was der Anwender da grad' gerne haben möchte und benötigt. Das Problem an der Sache ist nicht, dass Apple hier anders denkt, sondern das Problem an der Sache ist, dass Apple keinen adäquaten Ersatz für den Anwender bereitstellt, der ihm dieses Vorhaben, das er braucht und jetzt umsetzen will, ermöglicht. Der Anwender wird da im Regen stehengelassen, und es wird lapidar gesagt: Gibt's mit mir und in meinem Finder nicht! Und gleichzeitig beweisen Apple und andere Software-Hersteller an vielen anderen Stellen, dass Merging vom Ergebnis her (und nur das zählt für den Anwender) prinzipiell zu machen ist (wenn nicht auf die eine Weise, dann eben auf eine andere -- Hauptsache das Ziel -- das Merging -- kann umgesetzt und erreicht werden -- egal wie nun auf technischer Ebene umgesetzt und erreicht)!

Ich habe mit meinen zwei anderen Beispielen (OpenOffice/LibreOffice und Blog-Software) gezeigt, dass auch der stinknormale Anwender ganz schnell in eine Situation kommen kann, wofür er nicht unbedingt ein Entwickler sein muss oder sonstwie tiefer involviert sein muss in irgendwelche technischen Belange.

Man muss halt wissen was man kopiert. Wenn man das nicht weiß kann das immer zu Sicherheitsproblemen führen.
Kann ja auch bei der Erstinstallation des Programms passieren.

Aber da kann man ewig weiterdiskutieren
Grundsätzlich finde ich die Idee mit den Bundles eine sehr gute. Es gaukelt dem Nutzer vor dass ein Programm auch nur eine Datei ist, was die Verwaltung von Programmen viel benutzerfreundlicher macht.
Wie lösen das obige Problem denn Pathfinder & Co?

Diese Argumentation ist wieder mal völlig daneben, denn es gab bisher keine Updates, bei dem der Finder dazu benutzt wurde, Dateien auszutauschen, und es wird auch keine geben.

Und wieder ist die Diskussion durch sinnloses Geschwafel zunichte gemacht. Don't feed the trolls.

Folder Merging — Unlike previous versions of OS X, one can now merge files under two folders with the same name. A prompt will appear asking whether one wants to replace or keep both files

Hoffentlich bleibt das mit dieser Abfrage. Das letzte, was ich brauche, ist dieses dumme Zusammenmischen von Ordnern, dessen Ergebnis nie so ganz vorhersehbar ist. Ein Ordner ist ein Objekt, und ich will es durch das gleiche Objekt ersetzen. Fertig.

Ohne jetzt alle Beiträge bezüglich des Finders gelesen zu haben, die Leute, die die "Cut & Paste"-Funktion vermissen, können sich ja mal TotalFinder anschauen, denn diese Finder-Erweiterung ermöglicht eben genau diese Funktion (im "Windows"-Style) und Tabs + vieles Mehr. Nur mal so als Randbemerkung.

Gruß,
Muty

hoffentlich wird 10.7 mit der ersten Version ordentlich brauchbar. 10.5 und 10.6 war ja schrecklich.

Ich wäre schon zufrieden, wenn die erste öffentliche Version so gut läuft, wie die aktuelle DP.