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

Das is auch so gewollt, daß es kein Ausschneiden im Finder gibt.

Mac OS X ist im Gegensatz zu Windows wenigstens durchdacht.


PS: Ausschneiden mit Dateien funktioniert bei gedrückter CMD (Apfeltaste) und ALT (Wahltaste) Taste

Noch ein Wunsch: wie wäre es mit Skalierbarkeit der Systems statt alles in 72 dpi?
Auf den matten MacBook Pro-Displays wird mir alles deutlich zu klein...
Das nervt.

Apple macht die Hausaufgaben nicht *sick*

Was ist daran durchdacht? Und wie kannst du etwas aufgrund einer Fehlenden Funktion als durchdacht bezeichnen und danach die Funktion selbst noch nennen?

dom_beta:

Im Zweifel ist alles so gewollt, was irgendwie an den Bedürfnissen des Anwenders vorbeigeht...

Ich habe hier nicht den Windows-Begriff fallenlassen. Ausschneiden von Dateien im Dateimanager funktioniert auch unter anderen Bedienoberflächen, die es für Unix-Systeme gibt. Nur unter MacOSX gibt's das nicht.

Theoretisch oder auch praktisch?
Und weshalb klappt's dann bei mir nicht? Wieso zeigt mir mein Findermenü selbst dann immer noch im Menü "Bearbeiten" den Punkt "Ausschneiden ⌘X" als ausgegraut und nicht anwählbar an und offeriert mir stattdessen lediglich "Datei xy kopieren ⌘C"?
Was mache ich falsch?

sierkb
Es handelt sich bei der Funktion nur um Text welchen man ausschneiden könnte (wenn man Dinge umbenennt z.B.)

Vielleicht mal die Erweiterung TotalFinder testen da gibts ne Ausschneiden/Einfügen Funktion.

Soweit ich das noch in Erinnerung hab konnte man das aber auch in irgend einer Plist Aktivieren hat aber nicht wirklich funktioniert.

Üblicherweise kopiert man Dateien, man schneidet sie nicht aus.

Der Grund ist der, daß beim Verschieben ein Fehler auftauchen kann, was weiß ich, Strom weg etc. Dann ist die Datei hinüber.

Also kopiert man erst die Datei von A nach B und anschließend löscht man das Original A.

Drum gibt es eigentlich auch kein Ausschneiden in OSX.

Wie stellst du dir eigentlich die cut & move Funktion vor? Wie soll denn da was verloren gehen? Der Mechanismus ist doch genau der selbe wie bei copy & paste, nur dass nach dem Kopiervorgang eben die Ursprungsdatei gelöscht wird. Es passiert also genau das was man sonst per Hand erledigen muss. Gehen bei der manuellen Methode dann auch ständig Daten bei dir verloren? Ach doch nicht? Seltsam, du scheinst etwas falsch zu machen.

Wie ich diese Denke hasse. die Funktion gibt's nicht, das hat Apple so entschieden, also braucht sie der Bauer auch nicht.
Konsequenterweise dann bitte aber auch den App Store mögen, denn den, laut Apple, braucht man ja üblicherweise.

dom_beta:

Und warum funktioniert dann das Cut & Paste bei manchen Dateien sehr wohl, bei anderen aber wiederum nicht? Es funktioniert zum Beispiel bei manchen Dateien, wenn man sie mit gedrückter Maustaste anfasst und innerhalb seines eigenen Spielraumes (will meinen: Rechte-Spielraumes) irgendwoanders hinpackt. Zum Beispiel, wenn man ein Dokument aus dem eigenen Dokumentenorder hernimmt und es zu sich auf den Desktop packt. Dann wird dieses Dokument verschoben. Es wird im Dokumentenordner gelöscht und auf dem Desktop wieder hergestellt.

Und jetzt die Preisfrage: Warum geht DAS, während man beim diesem selbigen Dokument NICHT sagen kann: das markierte Objekt an dieser Stelle wegnehmen/ausschneiden/löschen mit ⌘X, dann mit der Maus auf den Desktop gehen, und dann dort mit ⌘V fallenlassen/einfügen.

Warum klappt das Eine per Maus und direktem Anfassen des Objektes, das Andere per Markieren und Maus und Tastatur an ein und demselben Objekt will aber nicht klappen? Beides ist ein- und derselbe Vorgang an ein- und demselben Objekt. Beides findet im eigenen Rechtebereich statt. Das ist inkonsequent von Apple und völlig unlogisch gemacht, und ich finde selbst mit angestrengtem Nachdenken keine Erklärung dafür, warum das mit Absicht nicht gehen soll und darf.

und was machst du, wenn du zunächst Datei 1 und dann eine andere anklickst?

Welche soll er dann nehmen?!

PS: kommst du aus der Windows-Welt?

Komische Debatte um cut & paste.
Wäre doch sehr einfach: das System löscht erst nach cmd v.
Wird nocheinmal etwas anderes ausgeschnitten, bleibt die Datei an ihrem alten Platz.
Wäre wirklich kein Problem.

Genau wie ich das schon beschrieben habe und wie das üblicherweise auch umgesetzt wird. Will man auf Nummer sicher gehen kann ja auch vor dem Löschen noch die Prüfsumme verglichen werden.
Was meinst du denn damit? Per cmd+x wird ganz klar definiert welche Datei verschoben werden soll.



Aber was soll's, die Diskussion ist völlig sinnfrei.

Welche soll er dann nehmen?![/quote]

Was soll da geschehen? Ich habe Dir grad' was beschrieben. Ein- und derselbe Vorgang an ein- und demselben Objekt einmal per Maus und einmal per Maus & Tastaturkürzeln. Einmal funktioniert's (Maus-only), das andere Mal funktioniert's nicht (Maus+Tastatur).
Und dann komst Du mit der Frage "Was wäre wenn?"... Nein -- nix "Was wäre wenn?".
Oder habe ich mich unklar ausgedrückt?

Willst Du mich beleidigen? Windows läuft bei mir in einer VM, und die schmeiße ich nur dann an, wenn ich mal irgendwas kurz im IE testen will. Also eher selten. Ansonsten nutze ich Windows schon seit über 10 Jahren nicht mehr.


TITAN:

+1

Die Antwort ist ganz einfach: Das lässt sich so nicht implementieren. Angenommen, die Datei ist 1TB groß. Beim Löschen (Cut) musst Du die Datei in der Zwischenablage halten, die sich im Hauptspeicher befindet. Wie willst Du das in der Praxis umsetzen?

Und wenn nach dem ersten Cut aus Versehen eine zweite Cut-Operation ausgeführt wird, ist das Terabyte an Daten unwiederbringlich verloren.

Ich sage nicht, dass Apple nicht eine benutzerfreundliche Ein-Fenster-Operation zum Verschieben von Dateien realisieren sollte, aber in dem Punkt hat dom_beta Recht: Das darf auf keinen Fall über die Cut-Operation realisiert werden. Cut bedeutet immer sofortiges Löschen.

Herrgott was ist denn das so schwer zu verstehen?
Noch mal: Die Datei wird wie bei copy & paste simple an den neuen Platz kopiert, während dieses Vorgangs liegt sie immer noch sicher am Ursprungsort, nach dem Kopieren und von mir aus nach dem Abgleichen der Prüfsummen von Ursprungsdatei und Kopie wird dann die Ursprungsdatei gelöscht. Ganz einfach, 100 % sicher, und vor allem: kann sogar Apple schon jetzt!
Und darauf spielt sierkb nun an. Per Maus ist cut & move nämlich durchaus schon in OSX implementiert, wenn auch in einer für mich undurchsichtigen Weise, ich bin mir manchmal nicht sicher ob nun kopiert oder verschoben wird, nur per Tastaturbefehl nicht. Es macht also wirklich, wirklich keinen Sinn das zu diskutieren.

Du lenkst ab. Ich habe von der Operation "Cut" gesprochen. Nur darum geht es. Du sprichst von zwei anderen Operationen.

Wie schon erwähnt, kann Apple den völlig anderen Ablauf, den Du meinst, gerne implementieren. Die Funktion muss dann aber "Ausgewählte Objekte für Folgeoperation markieren" heißen und darf nichts mit den Zwischenablageoperationen zu tun haben.

Diese Funktion gab es übrigens schon im System vor 20 Jahren, als Mac OS X noch von NeXT war. Dort gab es für das, was ihr meint, eine spezielle Ablage namens "Shelf". Das Konzept ist noch wesentlich benutzerfreundlicher, als das was ihr hier beschreibt, da sich dabei mehrere Auswahlen gleichzeitig in der Shelf befinden können, nicht nur eine.

Aber um die Anwender zufrieden zu stimmen, die von Mac OS auf Mac OS X umgestiegen sind, ist der Finder heute so mangelhaft, wie er sich im Moment darstellt. Man wird sehen, wann die Zeit gekommen ist, dass sich die Anwender nicht mehr an das klassische Mac OS erinnern und auch der Finder modern gestaltet werden kann.

Cmd-X Verweis auf Datei wird gespeichert Navigiere an einen anderen Ort Cmd-V Es wird ein normaler KOPIERVORGANG gestartet, die Ursprungsdatei bleibt wo sie ist Kopieren ist zu Ende Prüfsumme wird erstellt Wenn Prüfsummen gleich kann die Ursprungsdatei gelöscht werden.

Risiko für Datenverlust = 0...
So heisst sie aber unter Linux und Windows auch nicht...zudem ist Apple ja mit Datenverlust vertraut...man erinnere sich an den Bug mit der "Move" Funktion übers Netzwerk (Leopard)...da haben sie den Vorgang dann auch angepasst...die Funktion wurde NICHT unbenannt...

Und das ist falsch. Cmd+X bedeutet sofortiges Löschen des ausgewählten Objekts. Dafür ist diese Funktion da und so funktioniert sie in jedem Mac OS X-Programm.

Ja, und deshalb sind die grafischen Oberflächen dieser Systeme inkonsequent und nicht benutzerfreundlich.

An der ursprünglichen Stelle, vielleicht. Unter X-Window-Systemen ist und bleibt das betreffende Objekt dann noch im Pasteboard/Clipboard bzw. pbproxy gespeichert (z.B. für eine sich ggf. anschließende Dublizierung), bis es durch einen anderen Vorgang überschrieben wird.

Oder andersherum ist's bei MacOSX inkonsequent und benutzerunfreundlich. Oder man könnte es, wenn Du das Wort konsequent unbedingt benutzen willst, auch so formulieren: unter MacOSX ist es zwar konsequent, aber in diesem Fall dann wohl konsequent benutzerunfreundlich gemacht.

Die zahlreichen Clipboard-Erweiterungen, die es für MacOSX gibt und die diese wohl häufig vermisste Funktionalität nachrüsten bzw. auch mehrere Clipboard-Einträge inkl. History-Funktion (Du hast es oben ja selbst gesagt, dass es sowas bereits schon unter NeXTStep gab) ermöglichen, sprechen doch auch eine deutliche Sprache, dass es da wohl einen Bedarf gibt, der von Apple selber standardmäßig nicht befriedigt wird bzw. Apples Denkweise da offenbar konsequent an dem vorbeigeht, was die Nutzer offenbar brauchen und haben wollen.

Dieser Absatz reicht mir völlig aus als Eingeständnis, dass es da wohl durchaus Verbesserungsbedarf und Verbesserungsmöglichkeiten gibt. Und hier wohl einmal mehr die verklärenden Sätze gelten "It' not a bug, it's a feature." und "This page is intentionally left blank." , .

Ja, so ist das in allen Betriebssystemen. Und Du bist nun der Frage ausgewichen, wie Du diese Operation realisieren willst, wenn der Benutzer 1 TB an Dateien ausschneidet.

Ja, natürlich. Es hat nie jemand etwas anderes behauptet. Du hast aber behauptet, man könne das angeblich durch eine Cut-Operation lösen.

Wo ist denn da ein Eingeständnis? Es weiß jeder, dass der Finder Schrott ist.

Dumme Diskussion hier wg dem Cut&Paste und Ordner ineinander mischen. Beides kann OS X eben nicht und Windows kann es. Punkt. So ist das eben.

Und das man Cut&Paste mit der Maus machen kann, aber per Tastatur nicht, ist eben so bei Apple, weil Apple sich einen Dreck um wertvolle Details schert.

Apple kümmert sich lieber um das ganze Große statt um die kleinen wichtigen und wertvollen Details die das Leben angenehm machen.

Vielleicht gibt es ja bald im Zuge von Lion und der iOS Hinwendung kein Filesystem mehr, dann brauchen wir das alles auch nicht mehr

Wie macht's denn MacOSX, wenn man eine solche Datei mit der Maus anfassen und woanders hinziehen würde? Denn das geht ja offenbar.
Und wie macht's Apple (kramkram im Gedächtnis -- es kann sein, dass ich hier bei dem folgenden Beispiel irre) bzgl. des Löschens bzw. Leerens des Papierkorbs, wenn auf einmal eine Meldung/Warnung aufpoppt in der Richtung "Ich kann nicht alles auf einmal löschen, weil ich zu wenig Speicher habe"?

Siehe Antwort/Frage zuvor. Wie macht's Apple denn in den Fällen, wo es offenbar geht? Wie machen es Zusatzprogramme denn, die diese Funktionalität anbieten? Wie macht man es unter X-Windows?

Wobei es für den Nutzer eher unerheblich ist, ob eine Cut-Operation technisch tatsächlich so stattfindet oder irgendwie anders gelöst wird, für den Nutzer ist entscheident, dass es geht. Und wenn es im Normalfall geht und bei extrem großen Dateien nicht, dann bleibt immer noch die Möglichkeit, das dem Anwender auch irgendwie mitzuteilen. Macht MacOSX an anderer Stelle ja auch so, dass dann ggf. eine entsprechende Mitteilung kommt.

Ich meinte das auch weniger auf Dich bezogen, sondern allgemein gesprochen.
Durch Zufall gefunden, die Kommentare des Forums von TotalFinder fragen sich auch, warum MacOSX das nicht anbietet, obwohl es dazu mit hoher Wahrscheinlichkeit durchaus in der Lage wäre. Deshalb bietet TotalFinder es wohl an. Es geht also offenbar, und viele stellen sich die Frage, warum der Finder es eben nicht von Haus aus anbietet.

Die spannende Frage, die sich jetzt stellt, ist wohl: wie geht z.B. TotalFinder mit großen 1TB-Dateien um, wenn man da Cut&Paste machen würde, wie begegnet man dort einer solchen wohl nicht so unbedingt alltäglichen Extremsituation, wie löst TotalFinder technisch diese Herausforderung?

Du weichst der Frage schon wieder aus. Es geht hier nicht um ein Verschieben, sondern um die Funktion "Cut" (Ausschneiden). Das ist eine wohldefinierte atomare Funktion, die Du oben selbst erläutert hast.

Es geht nirgendwo. Du sprichst immer nur von Kopier- oder Verschiebevorgängen, niemals von Cut. Ist diese einfache Operation so schwer zu verstehen?

Ich wünsche mir sehr das mergen von Ordnern. Ich kanns eigentlich nicht verstehen, warum MacOSX das nicht kann.Immer dieses Einzelverschieben in Rahmen von Projektordnern ist echt anstrengend.

Als ob es in OS X keine kleinen, wichtigen, wertvollen, das Leben angenehm machende Details gebe! (Kopfschüttel)

Wie man die Fähigkeiten eines Betriebssystems auf's Dateien ausschneiden reduzieren kann, kann ich nicht verstehen. In jedem System gibt's Dinge, die den einen nerven und die der andere nicht mal kennt.

Es könnte doch z.B. über das Clipboard als Zwischenspeicher gehen bzw. über einen wie auch immer gearteten Zwischenspeicher (und/oder Ringspeicher bzw. LIFO-Stack). Mit dem potentiellen Risiko verbunden im Falle eines einfachen Zwischenspeichers ohne History bzw. ohne LIFO-Stack, dass eine evtl. zwischenzeitlich vorgenommene erneute Cut-Operation die vorherige überschreiben würde und somit die vorherige Datei weg wäre. Wahrscheinlich hat Apple deshalb das Ganze dann lieber komplett sein lassen oder nur halb umgesetzt (siehe unten), um dieses Risiko des evtl. Datenverlustes gar nicht erst aufkommen zu lassen.

Na, dann schau einer mal guck, was sich da u.a. bei MacOSX Hints findet:


Funktioniert auch unter Snow Leopard. Und plötzlich wird einem im Finder auch "Auschneiden" und ⌘X angeboten, das man auf Dateien anwenden kann. Allerdings: eine so ausgeschnittene Datei wandert in diesem Fall schnurstracks in den Papierkorb. Leider ist danach dann auch Schluss, man bekommt sie da mit ⌘V leider nicht wieder raus und irgendwo anders hinverpflanzt. Schade. Mal ein wenig weitersuchen und -lesen.

Aber immerhin schon mal so halb in die richtige Richtung. Das zeigt, dass Apple da durchaus sowas in der Art wenigstens angedacht hat, wenngleich auch nur halb umgesetzt und standardmäßig deaktiviert. Statt des Papierkorbs als Zwischenablage könnte Apple für ein Cut&Paste auch das Clipboard oder /tmp oder $TMPDIR bzw. $DARWIN_USER_TEMP_DIR nehmen und dann ein ⌘V erlauben, dann wäre das Ganze perfekt.

Immerhin. Mal weiterschauen, vielleicht kann man sich das ja auf der Grundlage irgendwie noch zusammenbasteln.

Nein, es muss über das Clipboard als Zwischenspeicher gehen. Ich wiederhole also zum x-ten Mal die Frage, wie das realisiert werden soll. Auch wenn Du wieder auf völlig andere Themen ablenkst, weißt Du wohl, dass das technisch nicht möglich ist.

Nein. Dann erklär mal einem Benutzer, der etwas auf einem File Server ausschneidet, warum er nach Drücken von cmd+X bei einer 1TB-Datei schätzungsweise 25 Stunden warten muss, bis die Operation beendet ist.

Nochmals zusammengefasst: Wir alle wünschen uns eine Dateiverschiebe, bzw. -kopieroperation, die durch zwei Vorgänge, nämlich eine Markier-, gefolgt von einer Zielauswahl in einem einzelnen Fenster aufgerufen werden kann. Wie dom_beta richtig gesagt hat, kann für den ersten Teil dieses Vorgangs aber auf keinen Fall die Funktion "Edit > Cut" (Bearbeiten > Ausschneiden) verwendet werden, da dies gegen wichtige Regeln der Mac-Bedienung verstoßen würde. Dass andere Betriebssysteme diese Funktion zweckentfremden, ist kein Grund, dies auch in Mac OS X so zu machen. Der Finder ist so schon schlecht genug. Apple hat (auf Basis von NeXT) dafür seit 20 Jahren eine bessere Lösung in der Schublade, die sehr viel einfacher und einleuchtender ist, als ein falsch verwendetes Copy/Paste.

Ich hatte oben einen falschen Link von MacOSXHints genannt, hier ist der Richtige:

Warum muss es über das Clipboard und nur allein über das Clipboard gehen? Warum kann da nicht auch im Bedarfsfall ein temporäres Verzeichnis oder eine Datei für herhalten, wenn der für das Clipboard reservierte RAM-Speicher dazu nicht ausreicht? Auf Dateisystem-Ebene ist das im Grunde ja nur eine Inode-Verschiebung. Wenn MacOSX RAM-Speicher auslagert oder erweitert, weil der physisch installierte RAM-Speicher nicht ausreicht, nimmt es doch auch eine Swap-Datei in Anspruch und schreibt da in diese Datei oder eine extra dafür angelegte Partition rein (alle Betriebssysteme machen das so), ohne dass der Anwender davon irgendwas mitbekommt. Da gäbe es also durchaus Möglichkeiten.

Erstens musst Du nicht den seltenen Extremfall zum Regelfall erklären, und außerdem ist da ein Weg so einfach wie bestechend: Im Zweifel einfach eine Warnung an den Benutzer, dass das aufgrund zu großer Größe bzw. mangels ausreichendem Speicher so nicht geht und fertig. An anderen Stellen gibt's doch aus ähnlichen Gründen auch eine Warnung bzw. Meldung des Betriebssystems, wenn etwas aufgrund zu großer Größe oder mangels ausreichendem Speicher nicht geht. Auch unter MacOSX. Wie machen es denn diese zahlreichen Erweiterungen, die diese Funktionalität nachrüsten? Wie wird's denn unter X-Window und GNOME und KDE gemacht? Wie wird's unter Windows gemacht? Die alle stehen doch in so einem Fall vor genau demselben Problem! Und da wird diese Funktionalität auch bereitgestellt. Trotz dieser Herausforderung.

Warum erinnert sich da ein Benutzer in jenem MacOSHints-Thread an Folgendes:

Hat er Unrecht? Erinnert er sich falsch?

Irgendwoher muss ja defaults write com.apple.finder AllowCutForItems 1 stammen, irgendeinen tieferen Sinn wird das ja wohl mal gehabt haben oder evtl. noch haben.

#

Ich finde, Apple sollte mit 10.7 die Desktop-Themes wieder einführen.

Ähnlich wie diese hier:

Ich will folder merging...(please Apple)

Weil genau das die Operation ist, die für den Befehl "Cut" (Ausschneiden) festgelegt ist.

Es gibt kein einziges Programm, das diese Funktionalität hat. Es gibt jedoch Programme, die Kopier- und Verschiebeoperationen unterstützen und die dabei fälschlicherweise den ersten Schritt auf die Funktion "Cut" legen, obwohl überhaupt kein Cut stattfindet. Ist das so schwer zu verstehen?

Auch so ein Punkt. Aber immerhin stellt Apple in seinen Developer Tools FileMerge.app zur Verfügung: /Developer/Applications/Utilities/FileMerge.app.

Damit kann man sich aushelfen. Nativ als selbstverständlicher Bestandteil des Finders, dass der Finder das entweder von sich aus macht oder man es im Finder konfigurieren kann, wäre es angenehmer.

Ebenso fehlt dem Finder, finde ich, ein UI, ein Button oder Menüeintrag, um versteckte Dateien anzeigen zu lassen. Die Funktion gibt's ja:
defaults write com.apple.finder AppleShowAllFiles -bool true|false. Nur hätte ich gerne dafür auch ein offizielles UI. Und am Besten nicht global für alle Finder-Fenster nach dem Motto "Alle oder keines", sondern individuell pro Finder-Fenster an und abschaltbar. Wenn man mit Webprojekten hantiert, braucht man ab und zu eine .htaccess-Datei. Die möchte man gerne auch im Finder dargestellt wissen und nicht einfach ausgeblendet, weil es eine dot-Datei ist. So wie es jetzt ist, muss der Benutzer/Entwickler basteln oder sich irgendwie behelfen mit einem Zusatzprogramm oder Skript (welches dann defaults write com.apple.finder AppleShowAllFiles -bool true anwendet), oder er muss gleich ins Terminal auf die Shell ausweichen, um solche dot-Dateien zu Gesicht zubekommen.

Das ginge sicher auch benutzerfreundlicher.
Aber wie Marcel Bresink schon richtig sagte: wir alle wissen, dass der Finder im Grunde sch... ist.

moveAddict 2.24 – Cut and Paste Files, Merge Folders $7.99

Cut and paste files using Automator and Applescript    free

Nein, eigentlich nicht. Das Programm "FileMerge" ist eine grafische Oberfläche für das Unix-Programm "diff". Man kann es z.B. verwenden, wenn zwei Software-Entwickler voneinander getrennt Änderungen an Teilen ein und desselben Quellcodes vorgenommen haben und diese Änderungen wieder zu einer Gesamtlösung vereinigt werden sollen. Das Programm heißt nur deshalb so, weil ein solcher Vorgang in Versionierungssystemen üblicherweise als "Merge" bezeichnet wird. Es ist zwar möglich, damit indirekt auch Ordner zu mischen, aber damit ist etwas ganz anderes gemeint, als was man von einem Dateimanager erwarten würde.

Marcel Bresink
Dem Benutzer ist es doch ***** egal wie das abläuft...der will einfach nur Cut&Paste ausführen wie er es von allen anderen UIs gewohnt ist...nur Apple stellt sich hier quer...ob mir da der RAM voll geballter wird, nur ein Alias auf die Dateien gespeichert wird oder was auch immer ist mir absolut egal.

Und warum benutze ich das u.a. genau dazu, um zwei Ordner miteinander zu mergen?

Ja. Aber nicht nur. Und trotzdem kann man damit auch zwei Ordner zu einem verschmelzen. Zumindest ich mache das so, und das funktioniert.

Und warum klappt das bei mir? Warum merge ich damit ab und zu zwei Ordner (hab's gerade eben nochmal ausprobiert)? Klappt wunderbar.

es geht ihm und apple doch nicht darum, wie das technisch geloest werden kann oder was benutzer andere systeme fuer verrenkungen gelernt haben.
die funktion "cut" ist systemweit dazu da, ausschneiden und dabei das objekt sofort(!) zu entfernen und in die zwischenablage zu legen. so kennt es der mac-user, so erwartet er es.
man koennte es wie in anderen systemen auch missbrauchen und fuer diesen speziellen fall eine andere funktionsweise programmieren, aber das waere eben nicht mehr konsistent.

"cut" schneidet immer überall sofort aus. das ist die funktion von "cut" und so funktioniert es systemweit ueberall. nur weil andere systeme diese funktion in einem spezialfall anders als systemweit integriert benutzen, muss man das doch nicht mitmachen.
die gewuenschte funktion koennte apple ja integrieren, aber dann unter einem anderen besseren menüpunkt. wo ist das problem? warum muss da unbedingt "cut" drauf stehen, damit ihr gluecklich seid?

demnaechst kommt noch jemand und moechte bei der funktion "sichern" in einem spezialfall etwas praktisches anderes haben.

fionda
Apple besitzt das EINZIGE grosse OS welches sich quer stellt...sie sind ganz alleine...keiner interessiert sich für Apples Lösung...was ist daran also konstant wenn man die gesamte Computerwelt betrachtet?
Gar nichts. Meine Güte blendet die ausgeschnittenen Dateien halt aus und vernichtet sie erst wenn der Nachfolgende Schritt in Aktion tritt...wo ist das Problem? Visuell kann man viele vorspielen...

nein, welches in diesem punkt konsistent ist!

du kapierst es nicht. es geht nicht um die technische umsetzung. das das geht, sieht man ja bei den anderen. es ist nur unsinn es mit "cut" zu machen. genauso koennte man fordern, dass nur im finder der fensterinhalt gedruckt wird, wenn man den einschaltknopf betaetigt. ist genauso sinnfrei und nicht zu erwarten.
"cut" schneidet immer sofort aus. ende punkt.

gegen den vorschlag eine solche funktion einzubauen, hat ja niemand etwas!
sag mir doch einmal ganz einfach: was stoert dich daran, wenn apple diese funktion einbauen wuerde und den entsprechenden menuepunkt nicht "cut", sondern anders nennt, wie marcel es auch vorgeschlagen hat?

Das ist richtig, aber Du verstehst es nicht. "Cut" ist eine einzelne Operation.

Absolut richtig. Die gewohnte Definition von "Cut" ist es, die gewählten Objekte sofort zu löschen. Millionen von Mac-Usern erwarten das. Wenn Objekte nach Drücken von cmd+X nicht gelöscht werden, würde Apple sofort Tausende von Bug-Reports erhalten, dass der Finder in diesem Punkt fehlerhaft arbeitet.

Ausblenden ist kein Löschen. Einem Benutzer, der Dateien per Cut löschen will, hilft das wohl kaum weiter.

Menschen ziehen an Türen obwohl darauf gross "stossen" steht...ein wenig aus der Luft gegriffen aber so ist es...nur weil ein "Cut" grundsätzlich so funktionieren sollte heisst das noch lange nicht dass dies jemanden interessiert.
Wo ist also das Problem wenn man hier inkonsistent gegenüber dem restlichen System und dafür konsistent mit dem Rest der Welt geht? Der "Usability" bringt es aktuell genau gar nichts...

fionda:

Dann nenne den Vorgang "Cut & Paste" halt "Verschieben". Oder, beide dazu nötigen Vorgänge einzeln benannt dann eben "Wegnehmen" und "Einfügen", wenn Du Dich so sehr an dem Wörtchen "Cut" störst, weil Du "Cut" mit was Anderem assoziierst...

Die Frage bleibt, warum es da für den Finder dann diese wohl standardmäßig deaktivierte bzw. nicht gebrauchte Funktion namens AllowCutForItems für die Datei com.apple.finder.plist gibt, Apple bei der Benennung dieser Funktion also höchstselbst das von Dir und Marcel nicht gemochte Wörtchen "Cut" bzw. "Ausschneiden" verwendet und im Finder ggf. freischaltet...

Abgesehen davon ist das nun echt ein Nebenkriegsschauplatz auf dem gebiet der Semantik, wie das Kind, diese technische Funktionalität da nach außen hin benannt wird -- Hauptsache, die Funktionalität wird überhaupt angeboten. Semantisch korrekt benennen kann man das Ganze immer noch, da wird sich schon eine zutreffende Bezeichnung für diesen Vorgang finden. Wenn nicht "Cut & Paste" bzw. "Ausschneiden & Einfügen", dann eben anders benannt.

ganz ketzerisch: warum sollte apple weiter inkosistent zum rest der welt sein und ohne geraetemanager und registry auskommen?
warum sollte apple weiter inkosistent zum rest der welt fenster mit apfel-w schliessen, statt Alt-F4?
den vorteil am mac war immer, dass funktionen und tastaturkommandos immer systemweit gleich funktionieren und heissen. auf anderen systemen ist das teilweise von programm zu programm anders, frueher war sogar programm schliessen je nach sprache des programmes unterschiedlich...

der usability bringt es eine ganze menge, wenn eine funktion immer gleich funktioniert und nicht in jedem programm anders.
noch mal: sag mir doch einmal ganz einfach: was stoert dich daran, wenn apple diese funktion einbauen wuerde und den entsprechenden menuepunkt nicht "cut", sondern anders nennt, wie marcel es auch vorgeschlagen hat? dann haettest du deine gewohnte funktion und(!) die usability waere eben nicht beschaedigt.

nicht ich assoziiere das damit, sondern die funktion "cut" ist in os x zwingend systemweit so vorgeschrieben.
ja, einfach einen anderen menuepunkt nehmen und den mit einer verschieben-funktion belegen, dass ist was marcel ja auch vorgeschlagen hat. das waere konsistent und wuerde eine von vielen gesuchte funktion ermoeglichen.
warum dazu unbedingt "cut" missbraucht werden muss, ist eben nicht nachzuvollziehen. ebenso gut koennte man verlangen, diese funktion hinter den menuepunkt "drucken", der im finder auch nicht da ist und mit dem du etwas anderes assoziierst, zu legen.

und diese funktion macht dann das von dir gewuenschte? ich glaube nicht...
kann natuerlich sein, dass sich apple der inkosistenz der restlichen welt irgendwann beugt. apple selber ist auch oft nicht konsistent. alleine schon die ampel-buttons in itunes! aber gut waere das nicht. besser ware es, die funktion als zusaetzliche moeglichkeit zu integrieren.

Siehe mein Posting zuvor. Es ist völlig egal, wie das Kind benannt wird, nur bitte anbieten sollte Apple diese Funktionalität. Es kann doch nicht sein, dass das Anbieten einer solchen Funktionalität nur daran scheitert, weil man keinen passenden Namen dafür findet.

Als Nutzer von mehreren Betriebssystemen das hier...denn Apple müsste dann ja auch einen anderen Shortcut als Cmd+X verwenden...und unter den 2 OS die ich bei der Arbeit nutze passiert da nun einmal etwas das ich so auch unter OS X (Zuhause) erwarte.

Nennen kannst du sie aber auch gerne "Käsekuchen"

Ganz einfach: Innerhalb von Apple wurde natürlich genau die gleiche Diskussion geführt. Man hat dann aber letztendlich entschieden, die UI-Regeln nicht durch eine falsch beschriftete Funktion zu ruinieren.

anscheinend ist es ja nicht voellig egal. es wird ja vehement immer gefordert die "cut"-funktion zu missbrauchen.

richtig: es waere gut, wenn es diese funktion geben wuerde. und marcel hat ja geschrieben, dass es etwas derartiges sogar besser schon in next gab. am suchen eines namens scheitert es wohl nicht. eher am willen von apple eine solche funktion wieder zu integrieren. das und genau das kann man sich wuenschen. kein thema. dagegen hat wohl niemand etwas. hat auch hier keiner geschrieben.
nur eben nicht einfach irgendeinen unpassenden menuepunkt (zb drucken) dafuer nehmen, nur weil der im finder gerade mal nicht benutzt wird...

Ok dann werde ich mir doch pathfinder zulegen... Es kostet einfach zuviel Zeit jedes mal in den Ordnerstrukturen einzelne Ordner zu verschieben.
Manche Projekte haben wahnsinnig viele Ordner...
Das ist ungefähr so, als wenn man 2 große itunes libraries hat, die man zusammenführen möchte...
Natürlich mit einigen gleichen Künstlern mit anderen Alben...
(ohne Verwaltung des Ordners in Itunes)

Ich hab's oben beschrieben, unter MacOSXHints steht's auch nochmal, und Du kannst es selber ausprobieren.

Diese Änderungen in den Finder-Preferences schaltet im Finder den Menüpunkt "Ausschneiden ⌘X" im Menü "Bearbeiten" und auch im Kontextmenü des Finders frei, und eine damit angewählte Datei wandert dann schnurstracks in den Papierkorb.

Immerhin.

Eben! Also sollte man hier mal nicht päpstlicher sein als der Papst (wieso muss ich da eigentlich immer an das Papsten und das danach benannte Speibecken denken? ) selber und sich erheben über andere Betriebssysteme, wenn man zugleich genug andere Baustellen hat, wo man total inkonsistent ist und teilweise seinen eigenen Vorgaben und Human Interface Guidelines widerspricht!
Nicht ausgerechnet bei einer so deutlich nachgefragten Funktionalität sollte man da jetzt "devil's advocate" spielen und auf Prinzipien rumreiten, auf die man an zahlreichen anderen Stellen im Betriebssystem eigentlich auch keinen gesteigerten Wert legt und an den betreffenden Stellen seine eigenen Regeln bricht.

Zum Bleistift.

Zum Bleistift.