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

last post from ZeHa at the

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

  • 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.

  • 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.

  • 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.