Hello, Guest the thread was called3.3k times and contains 171 replays

last post from ZeHa at the

Umstieg von Windows auf macOS – Irritationen [aus: Erste Macs mit ARM-CPU]

  • Da man jetzt auf YouTube und anderswo immer öfter sieht und liest, dass bisherige Windows-User aufgrund der neuen M1-Macs den Versuch eines Umstiegs wagen, sind vielleicht Erfahrungsberichte interessant. Ich habe hier das Video einer Frau entdeckt, die den Switch im Herbst gemacht hat (allerdings noch auf ein Intel-MacBook Pro 16"). Als langjähriger Mac-User wundert man sich manchmal, welche macOS-Eigenarten bei Windows-Usern zu Irritationen führen. Aber seht selbst:


  • man müsste erst einmal die Bedienung von Windows verlernen

    Ja, Apple sollte jedem Mac so ein MIB-Blitzdings dazu packen, das Windows-spezifische Kenntnisse einfach löscht. ;)


    Als sich die Frau im Video wunderte, dass man im Mac-Dock eine App nicht durch einen 2. Klick auf das Icon wieder beenden kann, fragte ich mich: Warum sollte man das wollen? Zumal ein Rechtsklick als nächstgelegenen Punkt im Kontextmenü "Beenden" anbietet. Insgesamt ist das Dock auch etwas anderes als die Windows-Taskbar – man kann das nicht 1:1 betrachten. Geht in W10 eigentlich Drag & Drop von Dokumenten auf Taskbar-Icons? Ich kann allerdings ihre Verwunderung etwas verstehen, was den roten Schließen-Button in der Fenster-Titelleiste angeht. Bei vielen One-Window-Apps schließt er die App gleich mit – aber bei Multi-Window-Apps wird halt nur das Fenster geschlossen und die App läuft weiter. Auf den aktuellen Macs ist es ohnehin fast egal, ob die App mitgeschlossen wird – weil das Neuladen nur noch ein oder zwei Sekunden dauert – früher war das wichtiger. (und ich verwende ohnehin cmd-Q für quit – wenn ich überhaupt mal ein Programm beende)


    Aber cool, dass sie das Starten von Apps über die Spotlight-Suche (cmd-Space) schon verinnerlicht hat. Windows-User machen das doch eher nicht so, oder?

  • Geht in W10 eigentlich Drag & Drop von Dokumenten auf Taskbar-Icons?

    Jou, geht auch.

    Windows-User machen das doch eher nicht so, oder?

    Doch, seit Windows 8 ist das eigentlich genauso üblich wie auf dem Mac.

  • seit Windows 8

    Sorry, ich bin mit meinem Wissen größtenteils bei Windows 7 stehen geblieben. Version 8 habe ich nie installiert gehabt (es sah mir zu gruselig aus) und mit Windows 10 mache ich eigentlich (sofern es geht) alles so, wie mit Windows 7. Von daher kenne ich so einige neu hinzugekommenen Features nicht. Drag & Drop auf Taskbar-Icons ging in W7 aber noch nicht, oder ist mein Kenntnisstand hier noch älter? Und die Windows-Suche als Programm-Starter zu verwenden habe ich nie ausprobiert, weil mir die Suche immer so träge vorkam.


    Aber wenn man das unter W10 jetzt ähnlich macht, wie beim Mac, dann erklärt das, warum die Frau das anscheinend verinnerlicht hatte.


    Was ich aber nicht nachvollziehen kann, ist ihre Irritation bzgl. der Menüleiste ("alles so verteilt"). Auch bei Windows ist eine Menüleiste oben – nur halt im Fester (welches man halt erst öffnen muss, wenn noch keines offen ist), nicht direkt oben am Bildschirmrand.

  • Ich arbeite schon seit Jahren parallel mit Windows, Linux und macOS... und am Mac passiert es mir immer wieder, dass ich mit "⌘+Q" ein @ Zeichen machen möchte. :S


    Dafür vermisse ich im Gegenzug unter Windows den Shortcut "⇧+⌘+V". Damit wird formatierter Text, welcher in die Zwischenablage kopiert wurde, unformatiert wieder eingefügt (eine sehr nützlich Funktion!). Zumindest konnte ich diese Funktionen noch nicht unter Windows finden (habe aber auch noch nicht sehr intensiv gesucht!). Bisher verwende ich immer den Workaround, den Text zuvor in einen reinen Texteditor zu kopieren, von dort dann erneut zu kopieren und dann unformatiert einzufügen.

  • Als langjähriger Mac-User wundert man sich manchmal, welche macOS-Eigenarten bei Windows-Usern zu Irritationen führen.

    Was mich auf dem Mac immer mal wieder zum Wahnsinn bringt ist die Unberechenbarkeit von Command-Tab: Nach zweimal Alt-Tab hintereinander unter Windows ist der Fokus garantiert wieder beim vorherigen Programm, bei zweimal Command-Tab auf Mac ist man zwar wieder in der gleichen Applikation, aber der Fokus ist nicht immer im gleichen Fenster wie vorher, besonders wenn man mehrere Monitore verwendet.


    Drag & Drop auf Taskbar-Icons ging in W7 aber noch nicht, oder ist mein Kenntnisstand hier noch älter?

    Dafür gabs ein Third-Party-Programm, welches ich unter Windows 10 weiterhin verwende weil es mehr Flexibilität bietet das die eingebaute Funktion.


    Dafür vermisse ich im Gegenzug unter Windows den Shortcut "⇧+⌘+V". Damit wird formatierter Text, welcher in die Zwischenablage kopiert wurde, unformatiert wieder eingefügt (eine sehr nützlich Funktion!).

    Control+Shift+V funktioniert oft, hängt aber davon ab, ob das einfügende Programm es implementiert hat.

  • Ich arbeite schon seit Jahren parallel mit Windows, Linux und macOS... und am Mac passiert es mir immer wieder, dass ich mit "⌘+Q" ein @ Zeichen machen möchte. :S

    Wobei das ein Spezifikum der deutschen Tastaturbelegung ist. In der (originalen) US-amerikanischen Belegung ist sowohl bei Windows als auch bei MacOS das "@" Symbol auf SHIFT 2. In der deutschen Variante hast du das @ unter Windows mit rechten ALT und Q, beim Mac mit ALT L. Beides nur eine Notlösung. Und in der Originalsprache, in der das System entwickelt wurde, stellt sich das Problem nicht. Von daher widmen sowohl Microsoft als auch Apple dem offensichtlich keine allzugroße Aufmerksamkeit.

  • In der deutschen Variante hast du das @ unter Windows mit rechten ALT und Q, beim Mac mit ALT L. Beides nur eine Notlösung.

    Warum ist das eine Notlösung. Die Windows Position von „@“ entspricht exakt der DIN 2137-1 in den Versionen 2012-6, 2018-12, 2020-12 Entwurf und ist damit die einzige standardkonforme Position des „@“ für die deutsche Tastaturbelegung.

  • Was ich aber nicht nachvollziehen kann, ist ihre Irritation bzgl. der Menüleiste ("alles so verteilt"). Auch bei Windows ist eine Menüleiste oben – nur halt im Fester (welches man halt erst öffnen muss, wenn noch keines offen ist), nicht direkt oben am Bildschirmrand.

    Das hat mich am Anfang bei macOS aber auch unglaublich irritiert: unter Windows gehört der Bildschirm außerhalb der Fenster ganz klar dem OS. In macOS ist das nicht konsequent so, insbesondere weil das Apfelmenü ja auch noch in der selben Menüleiste ist, und das ist ja wiederum klar ein OS-Element.

  • Was mich auf dem Mac immer mal wieder zum Wahnsinn bringt ist die Unberechenbarkeit von Command-Tab

    Ich weiß nur, dass ich damit den Programm-Switcher aufrufen und dann ein Programm per Tastatur oder Maus auswählen kann. Habe ich aber nach ein paar Mal ausprobieren wieder sein gelassen. Ich glaube, Apple hat das nur für Windows-Umsteiger eingebaut – einen Nutzen habe ich für mich nicht entdecken können. Wenn ich ein Programm nach vorne holen will, klicke ich entweder eines der geöffneten Fenster oder das Icon im Dock an. Aber ich bin vielleicht auch Maus/Pad-fixierter als die Coder hier.


    Die Windows Position von „@“ entspricht exakt der DIN 2137-1

    Die Frage ist wahrscheinlich, was zuerst da war oder ob der Erfinder dieser Norm über andere Systeme als Windows nachgedacht hat. Auf dem Mac steht cmd-Q für Quit seit 1984 fest und wenn man das weiß, ist es evtl. ungeschickt, auf die gleiche Taste (wenn auch nur im Deutschen und wenn auch mit einem anderen Modifier-Key) ein häufig verwendetes Zeichen zu packen. Ich kann mir die Position auf der Windows-Tastatur zumindest auch nicht besser herleiten als die auf der Mac-Tastatur (alt-L), von daher ist die Position reichlich random.


    Das hat mich am Anfang bei macOS aber auch unglaublich irritiert: unter Windows gehört der Bildschirm außerhalb der Fenster ganz klar dem OS.

    In allen Systemen gibt es kleine Ungereimtheiten. Trotzdem ist das aus meiner Sicht kein großer Showstopper. In beiden Fällen liegt die (horizontal angeordnete) Menüleiste oben – bei dem einen System liegt da noch die Fensterleiste darüber, beim anderen halt nicht. Der Vorteil für mich bei der Mac-Lösung ist, dass ich nicht übers Ziel (die Leiste) hinausschießen kann, wenn ich mit einer schnellen Handbewegung den Mauspfeil zum Menü bewegen will. Außerdem ist standardmäßig die Typo bei macOS größer (was man sicherlich in Windows ändern kann).

  • Die Frage ist wahrscheinlich, was zuerst da war oder ob der Erfinder dieser Norm über andere Systeme als Windows nachgedacht hat.

    Ich denke, die haben. In der DIN 2137-1:2012-06 standen beispielsweise indirekt Vorgaben drin (*), die das Treibermodell von Windows gar nicht umsetzen kann. Ähnliches gilt für die Tottasten (**), nur dass diesmal die Vorgaben direkt in der DIN-Norm standen. Hat noch nicht einmal ein Mitautor der Norm für Windows korrekt umsetzen können, was wohl dazu führte, dass die neueren Normen praxisgerechter sind.


    (*) waren dadurch drin, dass gewisse ISO-9995 Normen, an denen teilweise die selben Autoren mitwirken, eine nicht realisierbare Gruppenumschaltungstaste vorsehen.


    (**) Beispielsweise sollte das é eingegeben werden, indem man erst „e“ drückte und dann „´“.



    Und zur Frage, was zuerst da war:

    Anforderungen ändern sich. Heutzutage ist Vorgabe, dass mit der deutschen Tastatur alle Namen von Personen aus ganz Europa eingebbar sind, inkl. dem "Yılmaz" - und zwar, ohne Unicodepositionen auswendig zu lernen. Aber auch der Produktname "Pÿur" - was ich gerade mittels meiner DIN 2137-1:2018-12 konformen Tastaturbelegung beides mühelos eingeben kann.

  • Heutzutage ist Vorgabe, dass mit der deutschen Tastatur alle Namen von Personen aus ganz Europa eingebbar sind

    Mit welcher Windows-Version sind eigentlich weitere Tastatur-Ebenen hinzugefügt worden? Ich kann mich nur an die alten Zeiten erinnern, wo man mehrstellige Unicode-Zahlen eingeben musste, um Zeichen zu erzeugen, die nicht auf den Keycaps standen. Beim Mac gab es ja von Anfang an 4 Ebenen – normal, shift, alt und shift-alt. Und irgendwann hinzugekommen ist das Auswahlmenü, wenn man bestimmte Zeichen länger drückt (statt sie endlos zu wiederholen) – wahrscheinlich von iOS geerbt.

  • Mit welcher Windows-Version sind eigentlich weitere Tastatur-Ebenen hinzugefügt worden?

    Da wartet die DIN leider noch heuer drauf. Es spricht jedoch nichts dagegen, sich ein Tastaturlayout nach DIN 2137-1 von einem Drittautor zu installieren. Ich habe mir da mal eins selbst gebaut: http://www.e1-tastatur.de/


    Um mal zum Thema zurückzukommen - ein DIN 2137-1:2018-12 oder auch 2137-1:2020-12 konformes Tastaturlayout für MacOS wäre noch was...

  • ein DIN 2137-1:2018-12 oder auch 2137-1:2020-12 konformes Tastaturlayout für MacOS wäre noch was...

    Man ist ja doch ein Gewohnheitstier und beim jetzigen 4-Ebenen-Layout weiß ich einfach, was wo zu finden ist, z.B. das ™ oder ©. Für den seltenen Fall, dass ich doch mal ein Ÿ erzeugen muss, kann ich Y1 tippen – das reicht mir an Komfort.

  • Mag sein. Die Idee von einer Norm ist jedoch, dass auf jeden System, egal ob Windows, Linux, MacOS, Solaris, *BSD man die gleiche Tastaturbelegung vorfindet. Und ja, unter Linux ist die Belegung seit neusten auch verfügbar. Das bei älteren Linux Distrubitionen man noch bei der 2012'er Belegung ist, liegt nun mal in der Natur der Sache.


    Wobei die Norm explizit erlaubt, nicht zugewiesene Positionen nach Gurdünken zu belegen.

  • Die Idee von einer Norm ist jedoch, dass auf jeden System, egal ob Windows, Linux, MacOS, Solaris, *BSD man die gleiche Tastaturbelegung vorfindet.

    Trotzdem kommt mir im Wikipedia-Artikel zur Norm zu oft "Windows" vor, Windows kann dies oder das nicht – und die Position des @ (und die Erwähnung von alt-gr) ist sicherlich auch der Tatsache geschuldet, das es auf Windows-Keyboards schon abgebildet ist. Kein Wort darüber, wie die Norm auf anderen Systemen umgesetzt werden soll, die bestimmte Zeichen auf anderen Positionen abgebildet haben. SO wird es unter macOS sicherlich nicht viele Freunde finden. Zumindest für die Zeichen, die von der Geschichte her bei anderen Systemen woanders liegen (und die entsprechenden Tasten beschriftet sind), muss die Norm flexibel gehalten werden. Kein Mac-User wird sich mit einem offensichtlich von Windows inspirierten "Standard" abfinden, bei der man z.B. (aus Mac-User-Sicht unerfindlichen gründen) Q drücken soll, um ein @ zu erzeugen, obwohl es auf einer anderen Taste steht.

  • Trotzdem kommt mir im Wikipedia-Artikel zur Norm zu oft "Windows" vor, Windows kann dies oder das nicht

    Tja, man merkt halt, dass der Autor des Wikipediaartikels Windows Benutzer ist. Allerdings gehört zur Wahrheit auch dazu, dass als der Artikel geschrieben worden ist, ausschließlich der Windows Treiber von Herrn Pentzlin fertig gewesen ist (der übrigens auch der Autor des Wikipedia Artikels ist). Keine Linuximplementierung (die Unixe nehmen ja oft auch das xorg Zeugs). Und erst recht nichts für OS X.


    Der Artikel wäre also etwa so ausgegangen: Unter Linux passten fast alle Alt GR Belegungen nicht, die Tottasten sind unvollständig. Und unter OS X ist die Belegung ebenfalls nicht konform.

  • Warum ist das eine Notlösung. Die Windows Position von „@“ entspricht exakt der DIN 2137-1 in den Versionen 2012-6, 2018-12, 2020-12 Entwurf und ist damit die einzige standardkonforme Position des „@“ für die deutsche Tastaturbelegung.

    Um nochmal darauf zurück zu kommen: Nach Lesen des Wikipedia-Artikels bin ich mir recht sicher, dass es genau umgekehrt ist – die DIN-Position entspricht der deutschen Windows-Vorgabe – wäre dort das @ auf der L-Taste abgelegt (und abgebildet), dann wäre es jetzt sicherlich auch in der DIN-Norm so. Es gibt keinerlei anderen Grund, warum sich das @ unbedingt auf der Q-Taste befinden muss. Insgesamt scheint der Europa-Tastatur-Standard aber noch nicht wirklich in der realen Welt angekommen zu sein. Es gibt meines Wissens kein einziges Notebook mit entsprechenden Keyboard-Beschriftungen (und ohne diese muss man die Belegung auch erst lernen) und nur ganz wenige externe Keyboards. Ich würde den "Standard" noch als jung bis exotisch bezeichnen.


    Wer sich aber doch unter macOS eigene Keyboard-Layouts basteln will, kann dafür z.B. das kostenlose OpenSource-GUI-Tool Ukelele verwenden.