Hallo Besucher, der Thread wurde 57k mal aufgerufen und enthält 228 Antworten

letzter Beitrag von Retrofan am

Umstieg von Windows auf macOS – Irritationen (und Hilfe)

  • Das mit dem Speicherstand im Dokument ist sinnvoll, das loesen viele andere Programme auf ihre individuelle Art und Weise (meist durch ein Sternchen * im Titel oder in den jeweiligen Tabs). Das allgemein zu loesen ist sicherlich keine schlechte Idee. Da muss ich Apple jetzt AUSNAHMSWEISE mal loben ;) (wobei ich auch erstmal noch in der Praxis sehen muesste, ob das wirklich gut ist, oder ob das fuer manche Arten von Dokumenten/Anwendungen nicht passt. Ich denke da an MDI, sofern es das bei MacOS ueberhaupt gibt)

    Dein Hinweis auf MDI (multiple-document interface) fand ich im Nachhinein recht interessant und wichtig, um gewisse Unterschiede zwischen macOS und Windows zu erklären. Ich denke, manche Missverständnisse bei der Bedienung beruhen darauf, dass sich Windows (vor allem bis Version 7) und macOS auf den ersten Blick sehr ähneln und man daher wichtige Unterschiede kaum wahrnimmt. Der eine mag das als Segen ansehen, der andere als Fluch.


    Nein, MDI gibt es beim Mac (glücklicherweise) nicht – weil es nicht benötigt wird. Jaja, ich weiß, jetzt kommt wieder der Einwand, dass hier etwas schöngeredet werden soll. Aber ganz ehrlich, dann hätte ich dieses vergessene Thema gar nicht ausgraben müssen. ;) Man könnte auch sagen, dass es keiner besonderen Technik bedarf, um Multi-Fenster-Apps zu erzeugen.


    Jetzt die Auflösung: Windows-Programme liegen immer im Fenster. Das Programm-Fenster bildet also die oberste Ebene, in der sich dann die Menüleiste und alles andere eines Programms befindet. Also muss man dann natürlich auch über Fenster in Fenstern in Fenstern nachdenken, wenn ein Programm mehr als ein Fenster/Dokument öffnen möchte.



    Beim Mac gibt es dieses allumschließende Fenster nicht, ein Programm bekommt den ganzen Bildschirm zur Verfügung. Man kann sich das auch so vorstellen, dass jedes Programm einen eigenen, transparenten, Desktop öffnet, auf dem es dann frei walten kann. Wenn es nur ein Fenster öffnen will, dann ist das eine freie Entscheidung – es kann aber auf Wunsch auch ein Dutzend Fenster für ebenso viele Dokumente öffnen. Und der Entwickler kann auch frei entscheiden, ob er jedem Fenster die gleichen (MS Word) oder unterschiedliche oder gar keine Werkzeuge anheftet oder ob er eine zentrale Werkzeugleiste (wie bei Photoshop) nutzen will. Im Gegensatz zu einem opaken Container-Fenster, wie es Windows nutzt, kann man beim Mac zwischen den Fenstern eines Programms bis auf den (Finder-) Desktop durchgucken.


    Die (optische) Hierarchie ist also anders. Bei Windows ist es "Fenster/Programm/optionale-Fenster/Dokument", beim Mac ist es "Programm/Fenster/Dokument".


    Warum schrieb ich oben "glücklicherweise"? Nun ja, das Microsoft-Konstrukt führt manchmal zu Verwirrungen, zumindest bei mir. Bei MS Word auf Windows hatte ich es immer wieder, dass ich bei der Verwendung von mehreren Texten verwirrt war, wenn beim Schließen des letzten Textes das (übergeordnete) Programm beendet wurde, obwohl ich eigentlich danach einen neuen Text öffnen wollte – zack, da war einfach das Programm-Interface weg. Das kann man aber noch unter "ungewohnt" verbuchen.


    Was aber bei dieser Fenster-in-Fenster-Technik richtig nervig war (und vielleicht noch ist): man kann das Parent-Window kleiner schieben als den Inhalt und dann Fenster, oder (schlimmer) Dialoge außerhalb des sichtbaren Bereichs haben. Man weiß dann schlimmstenfalls nicht, warum ein Programm (z.B. die Menüleiste) nicht richtig reagiert (und schießt die App ab) – und in Wirklichkeit wartet das Programm nur auf die Bestätigung eines unsichtbaren Dialogs. Ohne verschachtelte Fenster kann das nicht passieren. Daher finde ich das Konzept nicht so glücklich.


    Aber es ist einfach eine andere Herangehensweise – nichts davon ist richtig oder falsch, halt nur anders. Es ist aber gut, wenn man die Unterschiede versteht – das erspart einem manchmal Verwunderung oder Ärger.


    Diese Fehlentscheidung [Mouseover war das Thema] sieht man ja auch gerne in Bildergallerien im Netz, wo man erstmal mit der Maus den Bildrand absuchen muss um die Schaltflächen zum vor-/zurückblättern zu finden, deren genaue Position am Rand immer irgendwo anders ist.

    Ich finde bei Userinterfaces, die für Maus optimiert sind, Mouseover-Effekte/Funktionen total OK, schließlich hat man die Möglichkeit. Was mich richtig nervt, ist, wenn es Interfaces gibt, die für Touchbedinung gedacht sind und die die üblichen "Mouseover"-Funktionen erst nach einer zusätzlichen Berührung darstellen. Ganz schlimme Entwicklung bei Videos: Früher (und bei VLC ist es noch so) lagen die Bedien-Elemente unterhalb des Videos – jederzeit anzufassen, jetzt legt man sie "platzsparend" als Overlay in das Video. Aber ausgerechnet bei der mobilen Version von YouTube muss man nun das Video erst einmal antippen, damit sich die Bedienelemente einblenden und man es z.B. pausieren oder spulen kann. Man muss also immer einen Doppel-Tipp machen, wo ein einzelner reichen würde, wenn man Pause und Zeitstrahl UNTERHALB des Videos zeigen würde. Wer macht so einen Mist?


    Dann ist das aber erst recht inkonsistent: Auch ohne Punkt kommt beim Klick auf den Schliessen-Knopf kam bei dem Fenster aus dem Screenshot eine Nachfrage, was denn jetzt mit dem Dokument gemacht werden soll.

    Ich habe das eben nochmal ausprobiert. Das von dir kritisierte passiert (bei mir) nur solange man dem Dokument noch keinen Namen gegeben hat – dann fragt das System/Programm beim Schließen quasi nach dem Namen. Sobald man es einmal gesichert (also benannt) hat, fragt das Programm bei einem Autosave-Dokument (ohne Punkt) beim Schließen nicht mehr nach, sondern beendet es, weil es ja immer aktuell gesichert ist. Das Verhalten ist also vollkommen korrekt und transparent. (Wie gesagt: Bei mir.)

  • Das ist mir bekannt und leider nicht zuverlässig

    Was soll daran nicht zuverlässig sein? Bei mir funktioniert es auf jeden Fall. So melde ich alle D64 (etc.) von einem Emu auf den anderen um und bisher hat das immer funktioniert.

    Ich hatte das bei vielen Tools. Ich hatte auch beim d64 so etwas als ich noch 3 verschiedene Emulationen installiert hatte. Ich konnte das so oft anklicken wie ich wollte er hat das nicht zuverlässig geändert. Ist dann vielleicht ein Benutzer-Fehler der aber tiefer im System liegen muss. Alt-Rechts-Klick bekomme ich doch noch hin. :)

  • Das habe ich bei Windows ganz anders erfahren. Hast Du den Treiber nicht, Pech, gibt es kein Programm dafür, Pech und so weiter.

    Was genau macht denn MacOS oder Linux besser wenn Du da den Treiber oder das Programm nicht hast?

    Terminal, Commando-Zeile. Dank der nähe zu Linux und Unix kann man über kleine Umwege Apps und Treiber davon nutzen.

    Bestes Beispiel aktuell ist Homebrew. Apple macht es schwieriger aber die Jungs die das machen sind echt nicht auf den Kopf gefallen.

    Ich erinnere mich das ich einen alten Drucker unter Windows nicht mehr nutzen konnte, auch für Mac gab es keinen Treiber dank CUPS konnte ich den Drucker noch lange nutzen.

  • Terminal, Commando-Zeile. Dank der nähe zu Linux und Unix kann man über kleine Umwege Apps und Treiber davon nutzen.

    Bestes Beispiel aktuell ist Homebrew. Apple macht es schwieriger aber die Jungs die das machen sind echt nicht auf den Kopf gefallen.

    Homebrew oder MacPorts ist nichts anderes als ein Paketmanager der Dir die Aufgabe abnimmt Software manuell installieren zu müssen. Ähnliches bekomme ich unter Windows mit Chocolatery oder Winget. Beantwortet aber nicht die Frage was MacOS/Linux besser macht wenn Dir ein Treiber oder Programm nicht zur Verfügung steht.

  • Retrofan Ich meinte mit "MDI" jetzt nicht unbedingt exakt das, was Microsoft frueher mal hatte (ist das nicht schon seit Word 98 anders, sodass jedes Dokument ein eigenes Fenster hat?), sondern mehr deskriptiv, also "Programm mit mehreren geoeffneten Dokumenten", egal ob das nun in Form von Tabs oder anderer Methode gemacht wird. Wenn jedes Dokument sein eigenes Fenster bekommt, dann ist der "noch nicht gespeichert"-Punkt in dem jeweiligen Fenster sinnvoll, wenn es jetzt aber z.B. Tabs sind, dann waere die Frage ob er dann genauso sinnvoll waere, oder ob das dann eher bei den jeweiligen Tabs angezeigt werden soll. Ein globaler "eines Deiner Dokumente wurde noch nicht gespeichert"-Punkt wuerde aber evtl schon auch Sinn machen. Also das war jetzt nur mal in den Raum geworfen. Und Fenster mit Tabs fuer die Dokumente gibts ja sicherlich in MacOS, oder?

  • Und Fenster mit Tabs fuer die Dokumente gibts ja sicherlich in MacOS, oder?

    Ich hatte ja hier schon geschrieben, dass quasi JEDES* Fenster Tabs aufnehmen kann, weil das im OS irgendwann eingebaut wurde. Mir ging es auch gar nicht mehr so um die seinerzeitige Fragestellung, sondern darum, die Unterschiede beim Aufbau zu erklären. Das erklärt halt vieles, z.B. warum bei Windows die Menüleisten nicht (ganz) oben ist usw. Gibt es denn dieses Fenster-in-Fenster-Prinzip in Windows nicht mehr? Kann man also nicht mehr Fenster so zusammenschieben, dass z.B. modale Dialoge außerhalb des sichtbaren Bereichs aufpoppen?


    *) Außer man programmiert am OS vorbei oder man verhindert es, weil man z.B. ohnehin schon eigene Tabs verwendet usw.

  • Wenn du einen modalen Dialog innerhalb eines Fensters aufmachst (als Child), dann hast du aber mächtig falsch programmiert. Das kann man so erzwingen, liegt aber dann auch an dem Programm, das das macht.

    Ein modaler Dialog hat als Owner das Anwendungs-Hauptfenster, aber nicht als Parent.

  • Also ich koennte nicht mit Sicherheit sagen ob es sowas in Windows noch gibt. Ich kann mich erinnern dass ab einer bestimmten MSOffice-Version die Dokumente stets in eigenen Fenstern offen waren, also als haette man die selbe Instanz der Anwendung mehrfach geoeffnet. Und ich glaube das war schon Office 98 oder 2000 oder so...

  • Ein modaler Dialog hat als Owner das Anwendungs-Hauptfenster, aber nicht als Parent.

    Wahrscheinlich korrekt. Aber was ist, wenn man das Anwendungsfenster nach oder vor dem Erscheinen eines Dialogs verkleinert? Schwebt ein Dialog dann außerhalb des verkleinerten Fensters oder positioniert er sich neu auf der Restfläche?


    Also ich koennte nicht mit Sicherheit sagen ob es sowas in Windows noch gibt.

    Der von mir oben verlinkte Text zu MDI auf den Seiten von Microsoft ist von 2018, auch wenn die Abbildung sicherlich älter ist.

  • Naja das ist halt eine Doku der Windows-API, und da das wohl nie rausgeflogen ist, wird das immer noch korrekt sein. Aber ob das faktisch noch von irgendwelchen Anwendungen genutzt wird und in welchem Umfang, das kann ich Dir eben nicht sagen. Wie gesagt, selbst bei Microsoft Office waere mir das seit ueber 20 Jahren nicht mehr bekannt.

  • selbst bei Microsoft Office waere mir das seit ueber 20 Jahren nicht mehr bekannt.

    Ich habe erlebt, dass Microsoft speziell bei Office Sachen ausprobiert hat, die erst später in Windows eingeflossen sind. Wenn mir jetzt noch einfallen würde, was das war, wäre es perfekt. ;) Dazu kommt, dass Office von Anfang an eine Multiplattform-Anwendung war (die es zuerst für den Mac gab) – von daher kann es sein, dass manche Bedienparadigmen so gewählt wurden, dass sie Windows- und Mac-Anwendern zusagen. Um zu sehen, was bei Windows üblich ist, sind MS-eigene Programme vielleicht nicht die richtigen. Ich habe mal gehört, dass auch 3rd-Party-Entwickler für Windows Programme schreiben. [edit: ;) ] ;)

  • Ich habe mal gehört, dass auch 3rd-Party-Entwickler für Windows Programme schreiben.

    Da brauchst Du jetzt nicht so sarkastisch werden, ich habe doch geschrieben, dass ich nicht weiss, in welchem Umfang das von anderen Anwendungen genutzt wird. Mir persoenlich sind aktuell jedenfalls keine bekannt. Vielleicht haette ich DAS hinzufuegen sollen. Allerdings bin ich auch schon seit 2009 kein Windows-Nutzer mehr, dennoch kann ich mich aktuell nicht erinnern, in der letzten Zeit davor wie danach nochmal an eine typische MDI-Applikation geraten zu sein.

  • Muss es denn immer gleich komplett spaßbefreit zugehen? Soll ich hier formulieren, wie in einem Lexikon oder Tagesschau-Beitrag?


    Das eine Problem, das ich beschrieb, hat mit MDI wahrscheinlich auch nur am Rande zu tun. Was passiert, wenn ich z.B. in Photoshop (o.ä.) einen bildbezogenen Dialog öffne und dann das Photoshop-Fenster so weit verkleinere, dass der Dialog nicht mehr sichtbar ist? Geht das überhaupt (noch)? Oder liegt der Dialog dann außerhalb seines Programmfensters oder verschiebt er sich beim Skalieren mit, sodass er immer sichtbar bleibt?


    (Ich würde das ja schnell selbst ausprobieren aber ich habe vor einiger Zeit meine ganzen Windows-VMs ausgelagert, weil ich den Speicherplatz sinnvoller nutzen konnte.)


    Mit Windows 10-Fenstern gibt es die MDI Technik wohl auch noch:


  • Terminal, Commando-Zeile. Dank der nähe zu Linux und Unix kann man über kleine Umwege Apps und Treiber davon nutzen.

    Bestes Beispiel aktuell ist Homebrew. Apple macht es schwieriger aber die Jungs die das machen sind echt nicht auf den Kopf gefallen.

    Homebrew oder MacPorts ist nichts anderes als ein Paketmanager der Dir die Aufgabe abnimmt Software manuell installieren zu müssen. Ähnliches bekomme ich unter Windows mit Chocolatery oder Winget. Beantwortet aber nicht die Frage was MacOS/Linux besser macht wenn Dir ein Treiber oder Programm nicht zur Verfügung steht.

    so scheint meine Aussage auf alten und teils falschen Erinnerungen zu beruhen.

  • Muss es denn immer gleich komplett spaßbefreit zugehen? Soll ich hier formulieren, wie in einem Lexikon oder Tagesschau-Beitrag?

    Na Du weisst doch, dass es in Apple vs. was anderes-Threads gerne etwas angespannt zugeht. Ein geschickt plazierter Smiley kann da Wunder wirken ;)

  • MDI wird es auch noch ewig geben. Einiges bietet sich dafür ja auch an, und rein aus Gründen der Abwärtskompatibilität wird das auch da bleiben.


    Das mit dem Owner vs. Parent meinte ich aber. Wenn du ein Fenster als Child einsetzt, dann bleibt es innerhalb des Fensters des Parents. Es wird eingebettet.

    Wenn du es nur mit dem Parent-Fenster als Owner erzeugst, dann ist es ein freiflottierendes Fenster.


    Das ist absolut unabhängig von MDI. Modale Dialoge macht man aber nie als Child, nur als ge-ownt-es Fenster. Die API gibt es her, irgendwelche Flitzpiepen haben das dann vermutlich auch mal gemacht.

  • Hier ist ein weiterer Erfahrungsbericht von einem Umsteiger:



    Was ich dabei spannend finde, ist, dass der Neu-User die Hardware (M1-MacBook Pro) zwar toll findet, mit dem OS aber immer noch Probleme hat. Ich wünschte dann immer, dass ich bei so Ein- und Umsteigern daneben sitzen und ihnen helfen könnte, die ersten (oder auch spätere) Hürden zu nehmen. Umsteiger neigen (natürlich) dazu, alles so machen zu wollen, wie sie es auf ihrem vorherigen System gelernt haben.


    Ein Kritikpunkt von ihm ist, dass man in iMessage nur iMessages empfangen kann. Er meint, dass er gerne auch mit seinen Android-Kontakten WhatsApp-Nachrichten austauschen will. Nun, eine WhatsApp-App gibt es ja für macOS (ich nutze sie schon seit einiger Zeit), ich sehe da also kein großes Problem – außer dass beide Apps halt keine Multi-Messenger sind. Dass er Infos aus SMS, die auf seinem iPhone ankommen, über die Zwischenablage in seinen Mac bekommen könnte, ist ihm vielleicht noch nicht aufgefallen.


    Seine Dock-Kritik kann ich auch nicht so ganz nachvollziehen. Er meinte schon in einem vorherigen Video, dass er die Programme nicht anhand der Icons unterscheiden könne (und offensichtlich reicht es ihm nicht, dass bei Mausover der Name angezeigt wird). Dass das Dock nicht auf allen angeschlossenen Monitoren gleichzeitig gezeigt wird, ist eine macOS-Eigenart, mit der man leben muss. Das wichtigste ist, dass man begreift, dass das Dock nicht dafür da ist, die Windows-Taskbar nachzubilden.


    Interessant finde ich, dass er mit der gleichen Funktion beim Mac struggled, die ich unter Windows unterirdisch finde: den File-Requester zum Öffnen von Dokumenten. Er hebt hervor, dass er bei Windows "einfach" den kompletten Pfad eines Explorer-Fensters Copy/Pasten kann. Das geht beim Mac nicht (anzeigen kann man den Pfad in Finder-Fenstern hingegen schon, was er nicht eingeschaltet hat), dafür aber Drag&Drop beliebiger Dateien/Ordner (sogar aus dem Fenster-Namen) aus dem Finder in den File-Requester. DAS fehlt mir bei Windows. Er macht das wahrscheinlich nicht, weil er die Funktion (meines Erachtens intuitiver und schneller als Copy/Paste von Pfaden) noch nicht gefunden hat und weil er (auch eine Windows-User-Eigenart) das Fenster des File-Requesters viel zu groß aufgezogen hat, sodass er den Desktop überhaupt nicht sieht.


    Zudem hat er offensichtlich das Popup-Menü oben im File-Requester übersehen, das ihm einen Schnellzugriff auf die Pfadstruktur und die zuletzt verwendeten Ordner erlauben würde. Meistens wird man dort fündig, wenn man an einem Projekt arbeitet.

  • Ich habe gestern auf meinem 2012er Mini erfolgreich Monterey installiert. Und wenn der nicht hops geht, habe ich damit lange noch Freude, ohne dass ich mir was Neues anschaffen muss.

    Und es ist einfach nur genial, wie Apple das mit der HD-Struktur gelöst hat: kein Theater mehr mit Partionieren - einfach einen neuen Container auf der SSD erstellen und schon kann man ein neues OS installieren. Alle installierten "OSse" teilen sich die Platte.


    Mir fehlt allerdings auch die Funktion, den Pfad zu copypasten. Das mache ich "immer schon so" und man kommt damit wirklich in Nullkommanix zum Ziel, das geht deutlich schneller als bei MacOS.

    Aber auch das ist bei mir so: ich habe mich dafür entscheiden, den Switch zu wagen und dass man da ein bisschen was umlernen muss, finde ich nicht schlimm.

    Ich komme prima klar, sind nur ein paar Kleinigkeiten, die mich stören (am meisten, dass es kein 1:1-Pendant für "paint.net" gibt :-) ).

  • Mir fehlt allerdings auch die Funktion, den Pfad zu copypasten. Das mache ich "immer schon so" und man kommt damit wirklich in Nullkommanix zum Ziel, das geht deutlich schneller als bei MacOS.

    Ich finde das Drag&Drop-Prinzip schneller, da es nur aus einer Geste besteht und nicht irgendwelchen wilden Maus-Keyboard-Kombinationen – einfach reinziehen, fertig. Man muss sich halt nur daran gewöhnen, wenn man es anders kennt. Ich bin auch froh über den Tipp mit dem Copy/Paste, weil ich mich immer gefragt habe, wie Windows-User mit ihrem Öffnen-Dialog klarkommen.


    Und es gibt ja noch das von mir erwähnte Shortcut-Popup (welches der Neu-User übersehen hat) mit der Ordner-History und die Spotlight-Funktionalität. Einfach im Suchfeld irgendwas vom gewünschten Ordnernamen [edit: Dateinamen] eintippen. Die Wege sind auf jeden Fall vielfältiger als sich nur durch die Pfade zu klicken (was ich nie tun muss).


    Wenn man den Desktop noch sieht nutzt man die Bildschirmfläche nicht gut genug aus

    Das sehe ich nicht so. Zum einen habe ich 2 Bildschirme, zum anderen ist einer davon 30 Zoll groß. Wenn ich auf dem ein Browserfenster komplett aufziehen würde, wären mir hier im Forum z.B. die Zeilen deutlich zu lang, andere Webseiten würden mir nur viel weiße Fläche zeigen. Ganz ähnlich bei vielen anderen Dokumenten-Fenstern (z.B. von Word oder Photoshop). Da gucke ich lieber partiell auf meine Desktop-Wallpaper und einige andere überlappende Fenster und Icons als auf leere Fläche.


    Letztlich benötige ich aber keinerlei dauerhaft sichtbaren Desktop, um Drag&Drop durchzuführen. Durch einen Klick auf das Finder-Icon im Dock (oder über den Windows-like App-Switcher) hole ich schnell alle Finder-Fenster nach vorne oder ich nutze Exposé (F3) oder springe per Wischgeste auf einen freien (Work-)Space.


    ich habe mich dafür entscheiden, den Switch zu wagen und dass man da ein bisschen was umlernen muss, finde ich nicht schlimm.

    Diese Einstellung finde ich gut.


    Ein Freund von mir geht diesen Weg auch gerade, allerdings mit einem MacBook Air M1 (Basis-Ausstattung). Bei ihm sehe ich immer wieder, dass er etwas unglaublich umständlich macht, weil es beim Mac anders funktioniert als bei Windows – er aber die "richtige" Alternative nicht kennt und dann riesengroße Umwege macht. Und wenn ich ihm dann mal über die Schulter blicke, dann denke ich: Was macht der da? ;)