Finder: Objekte nach eigenem Gusto anordnen — ein Easter-Egg?

Es gibt da zwei Probleme:

Fall 1: das Finder-Fenster ist, ob nun in der gewünschten und obendrein in (un-)geeigneter Weise begrenzten Größe zu klein, als daß da am rechten und/oder unteren Rand nicht noch mindestens eine weitere Reihe oder Spalte für Objekte frei ist. Dann führt praktisch jede Aktion, die ein Objekt an eine andere (freie!) Position verschieben soll, zu einer „Explosion“ und die bisherige (teilweise) Ordnung ist weitgehend hinüber.

Fall 2:

Ein Fenster, das zwar (s.o.) ausreichend Platz vorhanden ist und Objekte teilweise schon angeordnet wurden. Also etwas in dieser Art (hierfür bräuchte ich eigentlich eine Schrift mit fester Breite)¹:

a a a a a a a   b b b b   c c c c c   d d d d
a a a a a a a   b b b b   c c c c c   d d d d
a a a a a a a   b b b b               d d d d
a a a a a a a                         d d d d
a a a a a a a        Z Z Z Z Z        d d d d
a a a a a a a        Z Z Z Z Z        d d d d
                     Z Z Z Z Z        d d d d
e e e e                                      
e e e e   f f f f f   g g g g g g g   h h h h h
e e e e   f f f f f   g g g g g g g   h h h h h
e e e e   f f f f f   g g g g g g g   h h h h h

Die Plätze „Z“ sind erst mal leer. Dahin sollen alle „h“. (Immerhin: gleich breit und hoch!) Das kann funktionieren. Aber selbst wenn es nur ein Objekt ist, das auf diese oder ähnliche Weise verschoben werden soll, also an einen Ort, der scheinbar genügend Abstände zu anderen Objekten bietet, explodiert wieder etwas. Und schnell findet man heraus, daß „auch ein einzelnes ‚h’“ an der einen Stelle beim Versuch, es wo anders abzulegen, anscheinend größer, zu groß, wird.

Und: je nachdem, was beim Versuch des Anordnend wie ausgewählt wurde, wie es angefaßt wird und wo es abgelegt werden soll (ein wirkliches Schema kann ich bislang dabei nicht erkennen), verteilt sich der Inhalt des Fensters – nun, eben wie nach einer Explosion.

Früher einmal™ mußte man bei solchen Versuchen nur richtig herangehen, um das Finder-Fenster  … zu überlisten? Die zu verschiebenden Objekte fürs Verschieben „links oben“ anfassen und „irgendwo rechts unten“ an einer Stelle mit freiem Platz (v. a. „jenseits des Scrollbalken-Bereichs“) loslassen. Hat einfach geklappt.

───────

¹ Bräuchte? Wenn man das extern mit einem geeigneten Programm erstellt und hier einfügt, dann scheint es ja sogar zu klappen!

Also solche „Explosionen“ habe ich auch andernorts, beispielsweise in Kaufhäusern (o. ä.) und den da aufgestellten Demonstration-Rechnern ausgelöst. Da ich davon ausgehe, daß die da installierte Software „übersichtlich“ ist und auch die Benutzer-Einstellungen nicht unbedingt von dem abweichen, was das System nach der Installation vorgibt …

Aber: das läßt sich doch einfach an bald jedem Mac „mit aktuellem System“ nachstellen!

BTW: „Software-Fritzen“ (eigentlich nicht nur „Software-Fritzen“ — ist nicht böse gemeint, nur ein grob pauschales Bild, das von Entwicklern bis Anwendern Leute mit „das haben wir immer schon so gemacht“ Mentalität umfaßt), denen es sehr mißfällt, wenn „so ein popeliger und bestimmt nichts könnender/verstehender Anwender ‚irgendwas’ verstellt“, sind mir schon öfter untergekommen. Egal unter welchem Betriebssystem: wer was verstellt (obendrein: ohne zu hacken, ob nun mit oder ohne „ausführbarem Code“), hat schuld?

„Beim Mac“ ist mir das das erste Mal deutlich aufgefallen, als die permanente Sichtbarkeit von Scrollbalken (in gewissen Augen) „verboten“ wurde …

Der Ordner ist, scheint mir, dabei egal. Hier handelt es sich um einen, der speziell für dieses „Projekt“ auf dem Desktop erstellt wurde.

Die Daten da drin sind, wie erwähnt, „HTML + Quellen“. Dazu noch eine Projektdatei des Texteditors, die da später, „vor dem Image erstellen“, natürlich weg kommen soll.

Und die Ansicht ist, ich dachte, das ist offensichtlich, „Symbole“ und „am Raster ausgerichtet“.

Es sind die gezogenen Objekte, die sich explosionsartig verteilen. Und das, obwohl die, ob nun einzeln oder als Gruppe, eigentlich genug Platz fürs ablegen haben sollten. (Vgl. oben, „h soll nach Z“). Das passiert nicht jedes Mal, aber eben auch (um das Beispiel beizubehalten) „mit ‚h’, die vorher mitten zwischen den anderen ‚h’ lagen und ja auch irgendwie dahin gekommen waren; also gerade in der Anordnung kein Problem darstellen sollten.

Wenn die „Explosion“ erfolgt, fliegen die Objekte (meist Teile der ausgewählten) nach oben, nach rechts und einige verteilen sich mittendrin. Also an eben noch freie Plätze wie die gezeigten Lücken (welche die Orientierung erleichtern sollten).

Das einzig sichere, das ich dazu bislang erkannt habe: das Fenster muß „gut gefüllt“ sein, also rechts und unten höchstens noch für jeweils ein Objekt pro Zeile bzw. Spalte Platz bieten. Wann selbst einzelne Objekte in die eigentlich groß genug erscheinenden freien Stellen nicht mehr passen wollen, ist mir bislang völlig unklar. Weder Änderungen an den Einstellungen des Ordners (Symbolgröße, Schriftgröße) noch ein Verkürzen der Namen selbst aufs Minimum hat, soweit das überhaupt reproduzierbar ist, daran mehr geändert als daß es nach einer Änderung andere Objekte sind, die sich so verhalten.

Ein Erlebnis „mit aha drin“ hatte ich vielleicht noch: während eines vorsichtigen Versuchs, „meine“ Anordnung zusammenzustellen, hat ein „aufräumen“ einige der abgelegten Objekte minimal verschoben. Sollte denn da nicht sowieso alles am Raster hängen? Wieso sind dann da einige „daneben“?

Ergänzend kann ich noch sagen, daß mein Projektordner aktuell über 300 Objekte enthält. Aber: bei einem kleinen Versuch mit einem anderen, zufällig gewählten Ordner, der gerade mal 9 Objekte enthält, tritt dieses „explodieren“ auch auf. Sobald das Fenster klein genug ist. Lediglich der „Schaden“ ist, vmtl. aus rein numerischen Gründen, eher klein. Und: da macht der Finder, wenn man Objekte weiter unten, „unterhalb des vertikalen Scrollbalkens“ ablegen möchte, sogar noch einen Versuch, den restlichen Inhalt nach oben zu scrollen. Was dem Verhalten, das ich aus Zeiten von OS X kenne (für mich ist spätestens Ventura ein iOS! Und, was manche Dinge angeht, sogar sehr an Android angelehnt!), entspricht. Da gab es „wegfliegende Dateien“ nur, wenn man bei genauer Betrachtung und mit entsprechendem Willen tatsächlich einen Platzmangel sehen konnte (und dabei ignoriert hat, daß so ein Platz im Raster doch eigentlich immer genügen sollte, daß Dateinamen – wenn es denn klappt – ja auch mal schlicht genügend verkürzt dargestellt werden).

Ach ja: nein, die „Karo-Schritte“ habe ich bislang nicht unternommen. Zum einen komme ich aktuell nur dann dazu, hier etwas zu unternehmen, wenn ich entweder direkt an der Problemfundstelle beschäftigt bin, oder der Rechner von mir so mit anderen Dingen beschäftigt wurde, daß ich einige „freie Minuten“ zusammenkriege. Und wie ja schon erwähnt: das passiert nicht nur hier, an diesem Rechner und unter diesem Benutzer. Diese Unternehmung erscheint mir also nicht gerade zielführend.

Dem Support habe ich schon etwas geschrieben. Ob das genügt ist mir aber … nun, zweifelhaft. Schließlich paßt in den Dialog nicht übermäßig viel Text rein.

Was mich irritiert: bislang konnte ich diese „Explosionen“ schon öfter sehen. Hmmm… mal ausprobieren …

Sowas auch, da ist es jetzt plötzlich einigermaßen schwierig, den Effekt zu zeigen. Ein paar Mal beim Probieren, aber beim Aufnehmen … Vorführ-Effekt oder so. Immerhin: einmal hab ich es gut erwischt. Und: vielleicht ist es von der Zahl der Objekte (mit) abhängig? Mein großes Problemkind hat ja das Dreifache zu bieten — aber als Video sieht man dann nur noch was, wenn es nicht merkbar an Volumen zunimmt. Egal, man sieht erst mal zwei seltsame Lücken, Löcher im Raster, beim Umstellen auf „am Raster ausrichten“. Und dann …

Na prima: FCP kann mit so einem Bildschirmvideo nichts anfangen. Also: erst mal exportieren und dann passend schneiden und komprimieren. Fertig.

Jetzt … gibt es hier nur Videos, deren Quelle mein Router mit einer freundlichen 403 beantwortet. 😤

Ein Nachtrag:

… dann funktioniert das bei mir in den Ordnern ganz normal, ohne das irgendwelche Dateien an andere Orte springen.

Nach ein paar weiteren „Experimenten“ kann ich sagen, daß dieses „Explodieren“ ziemlich sicher dann auftritt, wenn das zum Verschieben ausgewählte „Paket“ so bewegt wird, daß sein rechter und/oder unterer Rand über das bisherige Ende des Finder-Fensters hinaus geht. Früher einmal™ hat der Finder einfach damit reagiert, daß der Darstellungsbereich einfach entsprechend erweitert wurde. Das ist nicht mehr der Fall.

Es hat „etwas“ gedauert. Bis ich ein Beispiel so festgenagelt hatte, daß es „gefilmt“ werden konnte. Jetzt weiß ich nur nicht, wie ich das hier präsentieren könnte. (Nein YT kommt mir nicht in die Tüte.)

Jedenfalls ist es manchmal ganz einfach zu finden, dann wieder gibt es „Ewigkeiten“ keine Probleme. Abhängig ist es wohl von so ziemlich jedem Parameter, der bei der Darstellung eine Rolle spielt: die Namen der Dateien (in ihrer jeweiligen Repräsentation, was zumindest die Höhe und Breite angeht – vlt. spielt ja sogar eine Portion Typografie auch noch eine Rolle), die gewählten Schriftparameter wie z. B. „Größe 10 Irgendwasse“ (nein, das sind keine Punkt oder Pixel!) — und, das habe ich kurz nach der Aufnahme des Videos gemerkt: ob Finder meint, mit „aufräumen“ doch irgendwas geraderücken zu müssen. Eigentlich ist ja „am Raster ausrichten“ gewählt. Aber aus „Platzgründen“ wurde mittendrin mal mit ⌘⃣+⃣ bzw. ⌘⃣-⃣ gezoomt.

Meine Vermutung: da iOS ja mittlerweile HTML-Basiert ist (ich mache aus verschiedensten Gründen keinen Unterschied zwischen „Handy“ und „Desktop“, und sei es nur die Android-Konfiguration! Aber auch meine Blicke in Xcode bzw. Playgrounds liefern absolut kein Argument gegen die HTML-Vermutung!), unterliegt die Darstellung den guten alten Rundungsproblemen. Denn: wer hat schon einen 96dpi-Montitor? — Wobei, die …Nase vom W3 weiß zwar exakt, wie lang die Arme der Smombies sind, hält aber die physikalische Auflösung eines Ausgabegerätes nur dann für ein konkretes Maß, wenn es „schwarz auf weiß“ druckt. Bildschirme? Die könnten, im Gegensatz zu Gedrucktem, ja in 50 Kilometern Entfernung …

Ergebnis: kein „aktuelles“ Gerät darf Pixel, Linien und damit auch Text „umbunt“, also ohne Anti-Aliasing und ohne Rundungsprobleme bei und um jede Darstellung ausgeben. Gut, die entsprechende Stelle der W3-Veröffentlichung spricht zwar nur von einer Empfehlung, den Leuten einfach 96dpi zu unterstellen. Aber das ist natürlich auch ein (*sic*) Starart. Wieso also auf konkrete (*sic*) Standards wie z. B. das MKS-System abstellen? Damit fallen ja zu wenige Rakten vom Himmel! …