Neues OS/GUI für den C64

Bo Zimmerman hat da was: http://www.zimmers.net/geos/docs/memmap.txt

Er hat auch andere interessante Informationen zu Geos: http://www.zimmers.net/geos/geodev.html

Zitat von TheRealWanderer

Bo Zimmerman hat da was:

Danke schon mal dafür. Da ich aber GEOS nicht programmieren möchte, wäre mir natürlich eine etwas gröbere Übersicht lieber. Notfalls kann ich mir das alles selber zusammensuchen aber wenn es eine Übersicht gäbe in der Art: von $abcd bis $wxyz: i/O-Routinen, von da bis da: Grafikroutinen, von da bis da mathematische Funktionen etc., wäre mir das natürlich lieber. Es geht ja nur darum, abzuschätzen, wie umfangreich so ein OS wäre.

Der 2. Link ist auch hilfreich, da man dort nachlesen kann, welche Funktionen GEOS Entwicklern anbietet. Das ist wahrscheinlich keine schlechte Basis für die eigenen Routinen, wobei man sicherlich nicht alles davon benötigt. Weder haben wir vor, ein eigenes Dateiformat (VLIR) zu erfinden, noch mit unterschiedlich großen Fonts zu jonglieren. Und auch bei Grafik-Primitiven würde ich sagen: Wenn jemand ein Grafikprogramm für NaxOS programmieren möchte, kann er sich selbst um seine Grafikroutinen kümmern. Was man natürlich ohnehin fürs GUI benötigt (gefüllte Rechtecke, Bitmaps ...), das könnte man natürlich zur Verfügung stellen.

Will nur kurz einwerfen, dass ich das Verb "etwas wo hinodern" ziemlich klasse finde.

Danke, M.J.

Schön, dass du antwortest.

Zitat von M. J.

Wie Du richtig ausführst, lassen sich zwei brauchbare Zustände beschreiben, von denen einer (Work) der Standardzustand für den laufenden Betrieb einer Applikation sein sollte. Leider befürchte ich, daß Deine letzte graphische Darstellung an einer Stelle nicht ganz korrekt ist.

Nur an einer Stelle nicht ganz korrekt? Da hatte ich mit Schlimmerem gerechnet. Die Stelle hatte ich ja auch schon als Schwachstelle ausgemacht, da ich dort nichts einzeichnen wollte, was meiner Idee Vorteile verschaffen würde, ohne wirklich zu funktionieren. Also hatte ich den Inhalt in beiden Zuständen erstmal gleich gelassen. Wenn ich deine Beschreibung richtig verstehe, darf ich im "Work"-Modus aber auch den Bereich ab $D000 als RAM nutzen (sollte dann aber trotzdem das Color-RAM an gleicher Stelle halten).

Zitat von M. J.

Wenn ich es richtig verstehe, soll nach diesem neuen Modell das Easyflashrom dabei (anders als vorher angedacht) keinen direkt auf dem Rom ausführbaren Code enthalten, sondern nur "Dateien", die für die Ausführung ins Ram kopiert werden. Dies hat mehrere Vorteile

"Vorteile" lese ich natürlich gerne. Im Hinterkopf hatte ich schon länger die Vorstellung, den eingeblendeten ROM-Bereich (nur) als Transportweg in den RAM-Speicher zu nutzen. Nur formulieren konnte ich das wohl nicht richtig – und ich wusste natürlich auch lange Zeit nicht, ob das überhaupt machbar ist. Mit Zeichnungen geht es von meiner Seite aus halt besser.

Wenn man sich aus dem EasyFlash 16KB-ROM-Päckchen holen kann, kann man diese natürlich auch vorher packen – falls es mal nötig sein sollte. So hat ALeX das auch bei unseren beiden Spielen "Space Lords" und "Monster Buster" gemacht. Im Modul sind das nur 16 KB und ausgepackt belegen sie fast das ganze C64-RAM. Der Decruncher ist, soweit ich weiß, nicht sehr groß. Aber fürs erste wird man sowas wohl nicht brauchen – man kann eine App ja auch in zwei oder mehr 16KB-Päckchen aufteilen.

Zitat von M. J.

Für die beiden Zustände Work und Load würde ich folgende Konstellation vorschlagen

Ich werde das mal in meine Maps übertragen und hier wieder veröffentlichen.

Zitat von M. J.

Dieses Speichermodell setzt zwar voraus, daß sich die wichtigsten Routinen ständig im Ram befinden, ist dafür aber praktisch am einfachsten umsetzbar und in der Ausführung schneller als das ständige Wechseln zwischen Rom-Routinen und Ram. Außerdem erspart man sich so einen Haufen Wrapper-Code.

Für "einfach" bin ich durchaus zu haben – auch weil dadurch meines Erachtens die Chance auf Umsetzung steigt. Denn für den Nicht-GUI-Teil suchen wir ja immer noch einen Programmierer.

Zitat von M. J.

Zuerst dachte ich, dies wäre eine gute Möglichkeit, den Speicher zu organisieren. [...] Dann jedoch dachte ich: Wenn Du immer noch vorhast, nicht nur einen Dateimanager, sondern ein OS zu stricken, wäre diese Aufteilung eher ungünstig.

Ich finde die Aufteilung trotzdem immer noch gut. Der Dateimanager gehört ja auch bei diesem Konzept nicht zum OS, sondern ist ein Teil der Home-App, die zusätzlich ins RAM geladen werden soll. Die Teile des OS, die permanent im Speicher liegen, werden eigentlich von allen potentiellen Apps benötigt, sei es das Memory Management, die (vielleicht mit FCIII-Code aufgepeppten) Kernal-Datei- und Netzwerk-Routinen (inkl. Requestern) oder eben auch die GUI-Toolbox für Formulare etc. Das soll ja auch die Apps selbst recht schlank machen.

Zitat von M. J.

Begründung: Bei einem OS ist die GUI bzw. der Fenstermanager bereits ein Aufsatz auf das OS. Im Grunde genommen sollte es möglich sein (wie z. B. bei Linux) eine GUI auszuwählen oder sogar ganz darauf zu verzichten. Wenn man z. B. ein Spiel für dieses OS schreibt, braucht man unter Umständen die Bitmap gar nicht, aber dafür mehr Speicher für Programm oder Daten.

Geschichtlich gesehen ist das mit dem "Aufsatz" nicht immer so gewesen. Die Ur-GUI-Systeme von Xerox und Apple vermischten OS und GUI recht stark. Sie sind nicht so modular aufgebaut, wie die späteren Clone. Und obwohl man dem modularen Ansatz ja auch weitere Vorteile unterstellen kann, wird er wohl hauptsächlich aus Kostengründen/Zeitersparnis entstanden sein. Man nimmt halt einfach MS-DOS oder GEM-DOS oder CP/M und packt dort einen Fenstermanager drauf, statt alles selbst zu programmieren. Das ist vor allem ökonomisch.

Ich glaube nicht, dass wir unbedingt so modular sein müssen (aber wenn es nichts kostet: gerne). Ich glaube nicht, dass man ein Spiel für dieses neue OS schreiben möchte, das die wichtigsten Funktionen des Systems nicht nutzen will. Wenn man das GUI (optional) rauswirft, was hat die Programmierung für das neue OS dann noch für Vorteile? Ok, vielleicht noch die angedachte WiFi-Verbindung. Die kann man aber auch sehr einfach selbst stricken, wenn ein WiFi-Modem schon den TCP/IP-Stack zur Verfügung stellt. Meines Erachtens stellt u.a. die GUI-Toolbox oder auch die Widget-Engine der Home-App den Anreiz dafür dar, spezielle NaxOS-Apps zu schreiben. Welcher Entwickler würde schon gerne ohne Not sein Publikum einschränken und ein Programm schreiben, dass zwar kaum von den Features eines neuen (und natürlich von einer Minderheit genutzten) OS profitiert aber nur darauf läuft?

Ich würde das Schichtenmodell (OS/GUI/App/PlugIn) natürlich trotzdem möglichst umsetzen, alleine, um eine Arbeitsteilung bei der Entwicklung zu ermöglichen. Aber nicht unbedingt, um zu gewährleisten, dass man den "Fenster"-Manager ersetzen kann. Wer das tun möchte – in Form eines Forks – gerne, aber das soll nicht zwingender Teil des Projekts sein, der es evtl. verkomplizieren würde. Wenn deine zuletzt genannte Speicheraufteilung aber keine Einschränkungen mit sich brächte, dann können wir auch die nehmen.

Aber ich sage mal so: Wer's macht, hat recht! Wenn sich also ein Core-OS-Programmierer findet, der eine ganz andere Speicheraufteilung favorisiert, dann soll er es machen – das wäre tausendmal besser, als wenn gar nichts passieren würde.

Zitat von M. J.

Um den Speicher im Bereich $d000..$dfff optimal nutzen zu können, wäre es besser, das Farbram ans Ende zu legen bei $dc00..$dfff

Klingt plausibel, habe ich jetzt so eingezeichnet.

Zitat von M. J.

Wie kommen die Daten vom Rom ins Ram? Einen Entpacker dafür heranzuziehen, ist keine schlechte Idee. Aber: Wo befindet sich der Entpacker? Man könnte ihn zusammen mit den Daten in der Rom-Bank ablegen.

Das schöne ist ja, dass das Entpacken das Verschieben ersetzt. Um es flexibel zu handhaben, würde ich den Decruncher einfach mit aufs jeweilige ROM packen und von dort aus starten. Oder aber man hat im ersten ROM diverse Routinen, wie Decruncher, zusätzliche GUI-Bibliotheken etc., die sich das System immer lädt (also 16 KB einblenden, Teile davon verschieben), wenn es sie benötigt. Decruncher müssten natürlich kurzzeitig im resistenten Bereich ab $C000 Platz finden, andere Bibliotheken könnten auch unters ROM gepackt werden.

Zitat von M. J.

Das Easyflash bietet eine Möglichkeit, schnell Sachen in den Speicher zu laden, aber das machen GeoRam und NeoRam und natürlich REU auch. Das zuletzt von Dir vorgeschlagene Speichermodell schreit förmlich danach, daß diese Modularten ebenso unterstützt werden.

Ich bin natürlich überhaupt nicht abgeneigt, wenn weitere Hardware alternativ unterstützt wird. Aber das EasyFlash passt schon sehr gut zu unserem Anwendungs-Szenario. Vor allem durch den (schnellen) Autostart.

Zitat von M. J.

... wenn ein Spiel (was letztendlich auch nur eine App ist) wie beschrieben die Option anbietet: "Quit to OS".

So ist das ja auch grundsätzlich vorgesehen. Nur glaube ich nicht daran, dass jemand ein Spiel schreiben wird, dass fast den ganzen C64-Speicher nutzt (und deswegen den Großteil des neuen OS überschreibt) und dann trotzdem zum neuen Desktop zurückkehren möchte. Mal abgesehen davon, dass bei Nutzung eines EasyFlashs ein Reset das gleiche tun würde.

(OK, für den vielleicht mal existierenden Web-Browser wäre es nicht verkehrt, einen Großteil des Speichers überschreiben zu können. Dafür könnte allerdings der Screen-RAM an seinem Platz bleiben.)

Ich hatte in einem meiner Mockups das geöffnete Haupt-Menü gezeigt, dass den Quit-Befehl beinhaltet. Wenn man das EasyFlash konsequent nutzt und die meisten neuen Apps dort mit hineinpackt/installiert (man kann Blöcke ja auch nachträglich flashen), geht das "Laden" von Apps so schnell, wie man es von aktuellen Smartphones kennt. Dann könnte man natürlich statt eines (oder zusätzlich zum) "Quit" ein "Switch" anbieten: Wenn wir im resistenten OS-Bereich eine Liste mit den zuletzt geöffneten Apps vorhalten, könnte man einen App-Switcher einblenden, mit dem man nicht nur immer wieder zur Home-App zurückspringen kann, sondern direkt jede andere (zuletzt geladene) App aufrufen kann (ohne den Umweg über den Desktop). Das wäre ein komplett anderes Feeling als man es sonst vom C64 bzw. GEOS her kennt.

Zitat von M. J.

Abschließend noch etwas zum Speicher für die Graphikkopie: Die Größe dieses Speichers würde ich gar nicht von vornherein festlegen, sondern flexibel gestalten. [...] Hierzu müßte die App der GUI lediglich mitteilen, wo sich der Graphikpuffer befindet und wieviele Kacheln darin Platz haben.

Das finde ich eine gute Idee. Die von mir angegebenen 3 KB sollten ja im Prinzip ja auch nur darauf hinweisen, dass man keine ganzen 9 KB fest dafür reservieren/verschwenden muss, da eigentlich nie der ganze Screen (bzw. ein Großteil davon) abgedeckt wird. Und das wiederum liegt an dem neuen Fenstermanagement. Aber variabel ist natürlich noch schöner.

Nachdem wir nun eine mögliche Speicher-Aufteilung und ein angedachtes Verfahren zum Laden aus dem EasyFlash definiert haben, kommen wir zur Abwechslung mal wieder zum Thema GUI. Ich denke, Hexworx wird sich vielleicht freuen, wenn ich da mal ein paar mögliche Standards festklopfe.

Ich habe einen Großteil der für ein GUI benötigten Elemente gestaltet und aufeinander abgestimmt. Als da wären: Labels, Einzeilige Textfelder, Scrollbereiche mit vertikalem Scrollbalken, Popups/Comboboxen, Buttons zum Hoch/runterzählen, Radio-Buttons, Checkboxen, Switches, Textbuttons, Gruppenrahmen, Back/Reload-Buttons, Tabs und Icon-Buttons.

Auf der linken Seite des Mockup-Screens kann man alle Elemente sehen. Sie liegen in einem Doppelzeilen-Raster, also mit 16 Pixeln Höhe (hier optisch dezent hervorgehoben), wobei die Bitmaps nicht höher als 12 Pixel sein sollen. Die anklickbaren Bereiche sind immer ganze Chars groß, bei Radio-Buttons z. B. 2 x 2 Chars (16 x 16 Pixel). Daher kann man sie schnell und angenehm treffen. Die Minimalgröße von aktiven Elementen beträgt üblicherweise nicht weniger als 2 Chars. Aktivierungen von Elementen werden üblicherweise durch Ändern der Vorder- und/oder Hintergrundfarbe angezeigt.

Buttons haben bei mir üblicherweise 8 Status. 2 davon lasse ich hier erstmal weg, da es sich dabei um den Mouseover Status handelt, den der C64 wahrscheinlich eh nicht behandeln kann. Bleiben bis zu 6 unterschiedliche Zustände eines Buttons: inactiv, normal, clicked (0, 1, 2) und nochmal inactive, normal, clicked für den eingeschalteten Status (3, 4, 5). Es gibt aber maximal 2 unterschiedliche Bitmaps (wie z.B. bei Radio-Buttons), alles andere wird mit Farben erledigt. Ich habe auf der rechten Seite des Mockup-Screens eine Tabelle angefangen, die die Bitmaps und die Farben für einige Elemente zeigt. Das kann man wahrscheinlich schön platzsparend im C64 ablegen. Man kann sehen, dass je nach Item-Art diverse Plätze nicht belegt sind, weil es den entsprechenden Status nicht gibt.

Weswegen man den (auch nur farblich hervorgehobenen) Mouseover-Status doch noch einführen könnte, wäre zur Anzeige des aktiven Elementes bei einer Tastatur-Steuerung durch Cursor-Tasten. Man kann das aber notfalls auch mit dem Clicked-Status erreichen und bei Click dann einmal blinken lassen.

Ein paar Sachen, wie aufgeklappte Menüs (Pulldown und Popup) fehlen noch aber ich wollte erstmal das Grundprinzip und die Gesamtoptik zeigen.

Eine kleine Anmerkung zu den Steuerelementen bei "WiFi" und "Cellular", die ja eigentlich von der Funktionalitaet her identisch sind mit denen von "thirsty" und "hungry". Ich habe leider nie verstanden, warum die Welt sich ploetzlich auf solch ein bescheuertes Steuerelement eingelassen hat. Eine normale Checkbox wie bei "thirsty" und "hungry" ist doch supereinfach zu verstehen, jeder Idiot blickt das. Nun kam aber Apple irgendwann auf die Idee, solche komischen Schieber zu machen. Die ganz am Anfang noch viel schlimmer aussahen als heute (damals ungefaehr so: [[ON]OFF]). Da konnte man ueberhaupt nicht verstehen, ob die Option nun aktiviert ist oder nicht, zumindest nicht ohne Erfahrung. Denn beide Varianten konnten theoretisch beides bedeuten - ist das lesbare Wort (z.B. OFF) das, was gerade aktiviert ist, oder ist das das, was passiert, wenn man den Schieber auf das Wort schiebt? Es war einfach unklar. Nun wurde das ein wenig verbessert, in dem es nun solche Schieber wie im obigen Bild geworden sind (also sowas: (o ) ), aber immer noch benoetigt man Erfahrung, um zu verstehen, ob links oder rechts nun an oder aus bedeutet, bzw. gefuellt oder nicht gefuellt bzw. farbig oder nicht farbig.

Ich kann es einfach nicht nachvollziehen. Da hatte man sowas eindeutiges (die Checkboxen [x]), und dann wird das einfach ohne ersichtlichen Grund geaendert - vermutlich allein aus dem Grund, "modern" sein zu wollen. Inzwischen hat sogar Windows und Android solche Steuerelemente. Es will einfach nicht in meinen Kopf.

Daher wuerde ich hoffen, dass bei einem C64-OS normale Checkboxen verwendet werden, und keine solchen Schieber. Da die Funktionalitaet der beiden wie gesagt an sich identisch ist, benoetigt man ja nicht beides.

Bei den Radio Buttons wuerde ich uebrigens aus dem selben Grund darauf verzichten, einen nicht gefuellten Kreis bei nicht gesetzter Option anzuzeigen. Es ist nicht eindeutig, wenn es nur 2 Optionen gibt. Daher wuerde ich den nicht gefuellten Kreis entfernen, und nur den gefuellten Kreis anzeigen bei einer gesetzten Option.

Bei sowas bin ich leider etwas empfindlich, ich finde naemlich Eindeutigkeit beim GUI-Design sehr wichtig. Daher dieses etwas ausfuehrliche Post.

Zitat von ZeHa

Eine kleine Anmerkung zu den Steuerelementen bei "WiFi" und "Cellular", die ja eigentlich von der Funktionalitaet her identisch sind mit denen von "thirsty" und "hungry".

Das habe ich früher auch gedacht aber das ist nicht der Fall. Du hast wahrscheinlich dahingehend recht, dass Apple die Schalter (für iOS) erfunden hat und dass später Google und andere dem Beispiel folgten und Checkboxen durch Schalter ersetzten (wo sinnvoll).

Checkboxen führen normalerweise keine direkte Aktion aus, sondern erst, wenn man den dazugehörenden Dialog (z.B. mit OK) bestätigt, während Schalter SOFORT etwas umschalten und damit auch jederzeit den Status anzeigen (nicht den gewollten, sondern einen überprüften). Schalter (zumindest bei iOS) überprüfen, ob der gewünschte Vorgang auch wirklich geklappt hat und schalten dann erst wirklich um (vorher gibt es eine Zwischenposition). Das kann u. U. eine Sekunde dauern (wenn man z.B. WiFi einschaltet).

Das ist dann auch durchaus ein (bzw. der) Grund, weswegen man eventuell auf die Schalter bei NaxOS verzichten kann – vielleicht ist der C64 gar nicht leistungsfähig genug, jede Schalter-Aktion SOFORT auszuführen. Ein Sammeln der Einstellungen mit abschließendem Bestätigen des Dialogs ist wahrscheinlich Ressourcen-schonender.

Okay in diesem Fall muss ich Dir recht geben, dass ich das tatsaechlich noch nicht aus der Sicht betrachtet habe. In dem Fall kann es durchaus sinnvoll sein, ein weiteres Steuerelement hier fuer einzufuehren. Die Darstellung halte ich aber trotzdem fuer grundsaetzlich problematisch (auch wenn mir jetzt auf die schnelle nix besseres einfaellt), laesst sich aber vermutlich durch "heutzutage weiss halt jeder was gemeint ist" rechtfertigen. Trotzdem sollte man sich auf jeden Fall bemuehen, die Darstellung so eindeutig wie moeglich zu machen, daher wie gesagt auch mein Hinweis bei den Radio Buttons. Auch wenn ich intuitiv vermutlich den gefuellten Button als "ausgewaehlt" betrachten wuerde, so muss man doch sagen, dass man den ausgefuellten auch als "dunkel" und somit "nicht leuchtend", den nicht ausgefuellten jedoch als "hell" und somit "leuchtend" interpretieren kann. Alleine die Farbigkeit als Indiz fuer den Zustand zu verwenden, finde ich generell nicht gut. Das hat mich auch ab iOS 7 (war es glaube ich) gestoert, da wurde ja die GUI stark simplifiziert und minimalistischer (was ich persoenlich sehr ironisch finde, da ich mich frueher immer ueber die ganzen 3D-Glas-Effekte beschwert habe bei modernen GUIs und mich jeder dafuer belaechelt hat; inzwischen sind wir beim genauen Gegenteil angelangt wo alles so superflach geworden ist dass man den Status nur mehr an der Farbe erkennen kann, siehe auch Windows 8/10). Ab jetzt wurden Status-Icons nur noch schwarz dargestellt, und wenn sie aktiv waren, weiss. Klar kann man jetzt raten und sagen, weiss wird wohl "an" bedeuten, aber einen konkreten Hinweis darauf hat man nicht. Besonders wenn man nun also den Fall hat, dass es nur zwei Optionen gibt (a la Ja/Nein oder Male/Female etc), dann sollte der gewaehlte Zustand etwas deutlicher dargestellt werden als rein durch eine andere Farbwahl.

So zuminest meine bescheidene Meinung

EDIT: Jetzt wuerde mich aber doch auch mal interessieren, wie vielen Usern der Unterschied zwischen Checkboxes und solchen Switches ueberhaupt klar ist, denn intuitiv ist das vermutlich auch nicht.

• Der Unterschied war mir klar, optisch und logisch aber worst case. Stimme da voll zu.

Mir war es schlichtweg wurst, glaub ich.

Zitat von ZeHa

Trotzdem sollte man sich auf jeden Fall bemuehen, die Darstellung so eindeutig wie moeglich zu machen, daher wie gesagt auch mein Hinweis bei den Radio Buttons.

Das ist ja auch mein Begehr. Wenn du dir aber mal einen Radiobutton angeguckt hast, der nur aus einem einzigen Kreis besteht, weißt du, dass das nicht immer optimal aussieht. Umso schlimmer, je größer er ist. Grundsätzlich kann ich deinen Einwand aber nachvollziehen, daher habe ich versucht, einen Kompromiss zu finden. Ich habe jetzt den inneren Kreis ein wenig durchbrochen, wodurch der hohle Button noch weniger aktiv aussieht.

Zitat von ZeHa

Besonders wenn man nun also den Fall hat, dass es nur zwei Optionen gibt (a la Ja/Nein oder Male/Female etc), dann sollte der gewaehlte Zustand etwas deutlicher dargestellt werden als rein durch eine andere Farbwahl.

Das sehe ich genauso. Deswegen gibt es bei mir (selbst bei NaxOS, das wirklich auf seinen Ressourcen-Verbrauch achten muss) ja auch immer zwei unterschiedliche Bitmaps, wenn es einen Status zu verdeutlichen gilt.

Zitat von ZeHa

Jetzt wuerde mich aber doch auch mal interessieren, wie vielen Usern der Unterschied zwischen Checkboxes und solchen Switches ueberhaupt klar ist

Ich schätze, dass der Anteil unter Usern bei 1% oder weniger liegt. Aber darum geht es ja nicht. Es geht darum, das Richtige zu tun. Selbst bei einem C64-GUI.

Zitat von enthusi

Der Unterschied war mir klar, optisch und logisch aber worst case.

Logisch betrachtet ist der Schalter das einzig Richtige. Wenn hier jemand was versaubeutelt hat, dann Google und MS, die anfangs einfach ein GUI-Element (die Checkbox) missbraucht haben für eine Funktion, für die es keine gute Analogie darstellt – das hat letztendlich bis heute zu Verwirrungen geführt. Ankreuz-Felder haben auch in der Realität nie zu einer direkten Aktion geführt – oder wurde je eure Wunschpartei sofort nach dem Ankreuzen auf dem Wahlzettel zum Wahlsieger gekürt? Man kreuzt eine oder mehrere Optionen an (oder macht Häkchen rein, weil MS das X schon als Symbol zum Schließen verbraucht hat) und dann schickt man das Formular (in realitas, wie auch virtuell) ab – und erst ab dann gilt es. Das einzig richtige GUI-Element, um direkt eine Funktion auszulösen und dabei den Status der Aktion anzuzeigen, ist ein Schalter. Jeder versteht, dass ein Schalter direkt etwas tut – ein Lichtschalter wartet auf keine weitere Bestätigung.

Es ist auch kein Wunder, dass Apple den Schalter (erst) bei iOS eingeführt hat. Für Checkboxen benötigt man eine zusätzliche Bestätigung, um sie "abzuschicken". Auf den kleinen Handy-Displays war (damals stärker als heute) aber wenig Platz, was dazu führte, dass man fast immer scrollen musste, um z.B. alle Einstellungs-Optionen zu sehen. Ein OK-Button am Ende einer langen Liste hätte wahrscheinlich niemand gefunden und daher mussten die Optionen selbstauslösend werden. Logische Konsequenz: Ein Schalter muss die Checkbox ersetzen. Apple gehört zu den wenigen IT-Firmen, die sowas wirklich verstehen, schließlich haben sie auch Checkbox, Radiobutton, Popup, Menüleiste und Pulldown-Menü erfunden (zumindest kannte die Vorlage, das Xerox-Alto-GUI, sowas alles nicht).

Ich muss aber zugeben, dass Apples ersten Darstellungsversuche eines Schalters (in den frühen iOS-Versionen) "suboptimal" waren. Man wusste als durchschnittlicher User wirklich nicht, in welcher Position der Schalter war. Das wurde deutlich besser, als der Schalter runder wurde. Und irgendwann hat man sogar, wenn ich mich recht entsinne, in die HIGs geschrieben, dass in den Schalter keine Beschriftung (da verwirrend) gehört, sondern höchsten außen etwas stehen darf. Die Einführung des neuen GUI-Elements ging also handwerklich etwas holprig vonstatten, war aber von der Intention her richtig.

Aber obwohl ich versuche, selbst bei einem C64-GUI alles so gut, wie möglich zu machen, kann ich wahrscheinlich auf den "Switch" durchaus verzichten. Wie gesagt: für direkte Aktionen ist der c64 wahrscheinlich eh zu schwach – die klassischen GUI-Elemente dürften also fast immer ausreichend sein.

So, hier kommen ein paar Detailverbesserungen: Man kann eine Auswahl an ausgeschalteten Radiobuttons sehen, wobei der mit dem durchbrochenen Innenkreis mein Favorit ist (den habe ich dann der Einheitlichkeit wegen auch in den Switch reingepackt). Aber im Gegensatz zur vorherigen Annahme könnte ich mich u. U. auch mit der Version ohne Innenkreis anfreunden.

Ich habe hier auch einen umrandeten Default-Button angelegt, wie man ihn vom alten Mac-System her kennt. Der passt sogar noch in das 16-Pixel-Raster. Ich bin aber, glaube ich, dafür, die Default-Belegung anders darzustellen. Falls die GUI-Engine es hergibt, fände ich einen durchlaufenden Farbwechsel echt nett – dann könnte man den "Pump"-Effekt der neueren macOS-Default-Darstellung nachahmen. Falls es andere Vorschläge gibt, bin ich dafür aber offen.

Die letzte Änderung betrifft 3 Elemente am unteren rechten Rand. Ich habe die Darstellung aus meinem File-Requester-Mockup entnommen. Es ist eine Spezialdarstellung, die sich dadurch auszeichnet, dass der Feld- bzw. Button-Inhalt in einer anderen Farbe dargestellt werden kann, als der (den Button/Feld-umgebenden) Hintergrund. Dafür wäre es erforderlich, das übliche Zeilenraster zu verlassen und die Elemente mittig auf einer 8-Pixel-Zeile (oder auch 24-Pixel-Zeile) statt einer 16-Pixel-Zeile zu positionieren (im Prinzip eine Verschiebung um 4 Pixel vertikal). Die Darstellung hat aber auch Nachteile, weswegen ich sie nicht als Default gewählt habe. Man muss halt wissen, ob man sich wirklich diese Ausnahmen gönnen will. Es kann u. U. besser aussehen, bringt funktional aber natürlich keine Vorteile.

Wahrscheinlich würde man programmtechisch jedem GUI-Item einen Namen verpassen, über den es aufgerufen werden kann. Jedes Item hat eine feste oder (z.B. bei Feldern) variable Größe und ihm werden 1 oder 2 (kleinere, wegen des Speicherverbrauchs) Bitmaps zugewiesen. Dazu Vorder- und Hintergrund-Farbe für jeden der 6 Status. Die Farben sind vom System vorbesetzt, können aber von jeder App verändert werden.

Ich hatte nochmal über die beiden Moueseover-Status nachgedacht, mich aber gegen eine Verwendung als Highlite bei Cursor-Steuerung entschieden. Ich denke, es wäre besser, sollte es überhaupt dazu kommen, den normalen Mauspfeil direkt auf auswählbare Elemente springen zu lassen, statt die Farben zu ändern. Das ist noch eindeutiger.

Zitat von Cyberdyne

Also ich habe auch schon Checkboxen (und Radiobuttons) erlebt, die direkt eine Änderung verursacht haben. Vielleicht waren das ja nur schlechte Programmierer!

Richtig. Deshalb gibt es die Verwirrung. Manche Checkboxen auf manchen Systemen (oder Webseiten oder Apps) tun direkt was. Aber aufgrund meiner Erklärung dürften sie das nicht. Der User fängt an, nach einem Bestätigungs-Knopf zu suchen, der nicht existiert – weil man ja nicht erkennen kann, dass er nicht benötigt wird. Mich macht es immer unruhig, wenn ich solche Dialoge vorgesetzt bekomme und nicht weiß, ob die Optionen direkt übernommen wurden und ich das Fenster jederzeit schließen darf, ohne etwas zu bestätigen. Bei Schaltern wird das Verhalten sofort klar.

Zitat von Cyberdyne

Was hält einen davon ab eine Checkbox direkt etwas auslösen zu lassen?

Wie gesagt, die Analogie passt nicht. Man kann natürlich in einem GUI alles mögliche tun und sich nicht darum kümmern, ob die Analogie stimmt. Und oft wird es trotzdem funktionieren (im Sinne von "verstanden werden"). Aber wenn ein und das selbe Element (Checkbox) zwei unterschiedliche Verhalten an den Tag legen kann (einmal eine Absichtsbekundung entgegennehmen und einmal direkt eine Funktion auslösen (und das Ergebnis anzeigen)), ist das halt schlechter Stil. Das ist nicht "tödlich" und anscheinend haben sich Nutzer bestimmter Systeme an die Ungereimtheit gewöhnt, aber man kann sowas natürlich auch von Anfang an vermeiden (was ich hier versucht habe).

Ich weiß natürlich, dass das schon sehr feine Details bei der GUI-Entwicklung sind aber warum soll man ohne Not etwas falsch machen, was man auch richtig machen kann.

Zitat von Cyberdyne

Wenn das so ist, dann fordere ich umgehend eine zusätzliche andere Art Radiobuttons, die sofort funktionieren, weil man das auch unbedingt unterscheiden muss!

Ich gehöre nicht zum Planungsstab der allumfassenden GUI-Behörde, daher kann ich nur auf irgendwelche Quellen zurückgreifen und daraus meine Schlüsse ziehen. Als Apple Radiobutton und Checkbox erfand (wie gesagt, meines Wissen taten sie das), mussten Dialoge immer bestätigt werden. Man hat sich um dieses Detail keinen Kopf gemacht, man wollte nur die beiden Funktionen unterscheiden können.

Als dann später (bei iOS) dieses Bestätigen nicht mehr funktionierte, weil der User es zu sehr übersehen konnte, hat man für die Checkbox eine bessere Alternative gefunden. Für den Radio-Button wahrscheinlich nicht, weil er entweder in den Einstellungs-Dialogen nicht mehr benötigt wurde (ich habe dort keinen gesehen) oder weil es ohnehin schon ein Knopf ist, dem man eine direkte Interaktion zutrauen würde. Wenn man ganz konsequent wäre, da hast du natürlich recht, müsste man nachträglich den alten (getrennt zu bestätigenden) Radiobutton in etwas anderes ändern.

Vielleicht hat man auch deswegen eine Überarbeitung des Radio-Buttons gelassen, weil schon in den 80ern die User dieses GUI-Element nur als rein virtuelles Element kannten und die Technik, dass ein Reindrücken eines Knopfes am Radio andere Knöpfe herausspringen lässt, gar nicht mehr IRL präsent war.

Zitat von Cyberdyne

Davon ab finde ich die Schalter genau wie den Rest der GUI Elemente wieder richtig schön gepixelt.

Vielen Dank.

Noch etwas zur Beruhigung: ich weiß überhaupt nicht, ob man diese ganzen Elemente überhaupt alle benötigt. Mir macht es natürlich Spaß, mir darüber Gedanken zu machen und sie auch zu zeichnen. Aber GEOS oder auch GEM kamen anfangs sogar ohne Radiobuttons, Checkboxen und Popup-Menüs aus, von Tabs oder Switches will ich gar nicht erst anfangen. Das ging auch – und ich hatte auch mit Elementen experimentiert, die eher den rudimentären GEM-Elementen entsprachen. Allerdings war mir das (und wahrscheinlich auch dem potentiellen User) zu steinzeitlich, daher habe ich einfach mal aus dem Vollen gegriffen und alles für den C64 adaptiert, was moderne GUIs sinnvolles zu bieten haben. Wie gesagt, vielleicht braucht man das gar nicht in dem Umfang.

GEM und seine Alternativen zu Checkbox, Radiobutton und Popup

Das ist nicht richtig, auch Radiobuttons lösen im echten Leben nicht immer sofort eine Aktion aus.