Hallo Besucher, der Thread wurde 111k mal aufgerufen und enthält 953 Antworten

letzter Beitrag von Retrofan am

Neues OS/GUI für den C64

    Zitat von Retrofan

    Wer an GEOS mitarbeiten will, kann das ja gerne (schon seit Jahren) tun – aber meines Erachtens wird daraus nie das werden, was hier gewünscht wurde.

    Sehe ich genauso... GEOS ist für das Vorhaben hier der völlig falsche Ansatz. Mir ist das klar, die meisten scheinen das eigentliche Problem aber konsequent zu ignorieren (sektorbasiertes Dateisystem, kann man schwer über Internet nachladen). GEOS ist dafür auch viel zu träge... das Thema sollte man also wirklich abhaken.


    Abgesehen davon hätte das dann genau das gleiche Problem wie das Konzept-OS hier: Es würde (außer mir) keiner daran arbeiten... aber jeder würde jammern wie langsam der Sch... ist :D


    Könnte man da nicht so was wie einen Programmierwettbewerb draus machen? Jetzt nicht für das gesamte OS, aber z.B. die kleinste Routine um die Oberfläche zu zeichnen. Inkl. einer Fenster-Routine.


    Oder eine Mausabfrage die links/mitte/rechts+Rad unterstützt?


    Also erstmal nur Codeschnippsel sammeln. Setzt natürlich voraus das die Vorgaben klar sind (z.B. Grafik-/Char-Modus). Wo die Routinen im Speicher liegen wäre ja erstmal egal...

    Zitat von darkvision

    Setzt natürlich voraus das die Vorgaben klar sind (z.B. Grafik-/Char-Modus).

    Also, die sind hier einigermaßen klar definiert, schon alleine über Thread-Titel/History und Umfeld. Dieser Thread ist u.a. aus einer Unzufriedenheit mit GEOS entstanden, stellt aber dessen Verwendung des Bitmap-Modes nicht in Frage, weil sich dadurch tolle neue Möglichkeiten bieten, die im Textmode nicht möglich wären. Und wer ein umfangreiches OS mit Textmode-UI sucht, muss ja nur auf den Release von Greg Naçus C64-OS warten – da sollte man gar nicht versuchen, jetzt noch mitzuhalten.


    Zitat von darkvision

    Inkl. einer Fenster-Routine.

    Die würde man bei meinem Entwurf z.B. gar nicht benötigen (falls du mit Fenstern sowas meinst, wie man von Windows kennt). Trotzdem gäbe es natürlich etliche Basis-Routinen, von denen auch mein GUI profitieren würde. Einige davon gibt es sogar schon, nur nicht hier gesammelt, wie z.B. sehr schnelle Routinen zum Zeichen von Linien/Flächen und zum Bitmap-Scrollen. Eine weitere, noch zu erstellende, könnte eine proportionale Font-Zeichenroutine sein.

    Zitat von ZeHa

    Gab es nicht bereits schon Dokumente zur Speichereinteilung usw?

    Gab bzw. gibt es – aber noch aus Vor-WiC64-Zeiten, mit dem EasyFlash als (ROM-) Speichererweiterung.


    Das ist halt auch die Krux z.Z.: Wer das "Ding" nicht programmiert, kann ja nur (wie ich) Anregungen geben und neue Ideen in die Welt setzen – letztlich muss aber ab einer konkreten Umsetzung jemand (halt ein hauptverantwortlicher Programmierer) entscheiden, was denn die konkreten Hardware-Voraussetzungen (aus dem Vorschlags-Potpourri) sein sollen. Zumindest, wenn es um die Speicherverwaltung geht – die würde mit einem WiC64 halt anders aussehen als mit einer REU oder einem EF. Man sollte natürlich über grundlegende Entscheidungen auch reden können, weil letztlich jede (größere) Entscheidung dazu führen kann, dass das Ergebnis in eine falsche Richtung läuft und man z.B. die drölfzigste schicke Techdemo (wie Atari GOS oder Z80 SymbOS) erhält (was wir ja nicht wollen).


    Grafikroutinen sollten davon aber nicht betroffen sein – höchstens halt, was den Speicherbereich angeht, nicht aber das grundsätzliche Prinzip.

    Mal etwas ganz anderes: In einem anderen Thread habe ich darüber nachgedacht, ob man mit einer normalen 2-Tasten-Maus, wie der 1351, auch Scrolling (ähnlich einem Scrollrad) realisieren kann, ohne den Scrollbalken (bzw. Buttons) im GUI bemühen zu müssen. Meine Idee dazu ist, dass man innerhalb eines "Fensters" beide Buttons gleichzeitig drückt und dann die Maus bewegt, um den Inhalt zu verschieben. Ich hoffe, es wird klar, wie die Geste gemeint ist.


    Ich kam darauf, weil ich ganz ähnlich auf meinem MacBook den Fensterinhalt verschiebe: Mit 2 Fingern, die ich auf dem Touchpad horizontal oder vertikal (oder beliebigen anderen Winkeln) in die gleiche Richtung bewege, wenn sich der Mauszeiger über einem scrollbaren Bereich befindet.


    Der Vorteil im GUI: man könnte vielleicht optional die Scrollbuttons weglassen und nur den Scroll-"Balken"/Index zeigen. Außerdem müsste man nicht extra dorthin steuern, sondern könnte (wie mit einem Scrollrad) direkt über einem Bereich mit dem Scrollen beginnen. Aber es ist mir auch klar, dass das bei längeren Scrollbereichen nicht mehr wahnsinnig komfortabel ist, weil man die Maus irgendwann neu ansetzen müsste (wenn man an der Tischkante ankommt) – nur sehe ich beim C64 ohnehin nicht die riesigen Dokumente, wie ich sie auf meinem Arbeitsplatz-Rechner habe.


    Aber ich weiß nicht, ob diese Geste bei anderen Systemen evtl. schon anderweitig belegt ist oder sie, außer mir, niemand versteht (natürlich benötigt man etwas Gewöhnungszeit). Was meint ihr – wäre das einen Versuch wert?

    Noch etwas zu Mäusen bzw. Touchpads, weil die für GUIs schon recht wichtig sind und die Arbeit damit stark erleichtern (ich als jemand, der GEOS damals™ mit dem Joystick bediente, weiß das): Ich habe mit den WiC64-Entwicklern Rücksprache gehalten und nachgefragt, ob es rein vom Prinzip her möglich wäre, eine übliche PC Bluetooth-Maus über das WiC64 an den C64 zu bekommen – und das wurde (grundsätzlich) bejaht. Praktisch ist die Wahrscheinlichkeit auf Umsetzung aber momentan eher gering, weil das keinerlei Priorität hat (geringer Bedarf) und der BT-Stack auch knappen Speicher benötigen wird – allerdings können sich an sowas auch andere Programmierer beteiligen, der Bereich des ESP 32 (dort steckt der BT-Controller) ist Open Source.


    Ich wollte das hier mal erwähnen, weil es natürlich der Knaller wäre, wenn man über so eine günstige Erweiterung, wie das WiC, alles was man für ein "modernes" OS mit GUI benötigt, geliefert bekommen könnte, sogar die Maus-Schnittstelle für aktuelle OPTISCHE Mäuse (mit Scrollrad).


    Das soll kein Ausschluss-Kriterium für andere C64-Erweiterungen sein – auf vielen anderen Modulen/Erweiterungen (wie z.B. Sidekick) sind ja auch USB und/oder Bluetooth vorhanden und man könnte das wahrscheinlich auch dort umsetzen.


    Mir geht es nur darum, mögliche Vorbehalte gegen GUIs aus dem Weg zu räumen – und die begrenzte Verfügbarkeit von C64-kompatiblen Mäusen könnte ja einer sein. Daher meine vorsichtige Entwarnung: Gäbe es ein OS mit GUI, gäbe es auch wohl auch eine ausreichende Maus-Versorgung, entweder über moderne PC-Mäuse oder aber über Neuauflagen klassischer Mäuse. Wo Bedarf entsteht, gibt es über kurz oder lang auch ein Angebot.

    Zitat von Retrofan

    Aber ich weiß nicht, ob diese Geste bei anderen Systemen evtl. schon anderweitig belegt ist oder sie, außer mir, niemand versteht (natürlich benötigt man etwas Gewöhnungszeit). Was meint ihr – wäre das einen Versuch wert?

    Versuch macht kluch. Auch wenn sich das in meiner Vorstellung nicht so praktikabel, sondern eher umständlich anhört. Mit einem Touchpad ist das ja easy, aber als Mausgeste? Nutze ich persönlich nirgends, wo das unterstützt wird. Am C64 ist das vielleicht sowieso noch mal etwas anderes und wie gut sich die Mausgeste tatsächlich "anfühlt", dürfte sehr stark von der Scrollgeschwindigkeit abhängen.

    Naja letztendlich würde man ja in dem Moment mit der Maus keine andere Bewegung durchführen als wie wenn man einen Scrollbalken anpacken würde, was ja zuvor meist gemacht wurde (die Pfeile an der Scrollbar wurden ja eigentlich irgendwann von gar keinem mehr verwendet, so mein Eindruck). Nur dass man eben die Maus nicht erst zu einem etwaigen Scrollbalken bewegen müsste.


    Oder ist das eher so gemeint, dass man die Scrollgeschwindigkeit regelt und das Scrolling dann alleine losgeht, sobald man die Maus aus der Initialposition herausbewegt hat?

    Zitat von -trb-

    Nutze ich persönlich nirgends, wo das unterstützt wird.

    Meines Wissens gibt es das ja auch noch gar nicht – ist mir zumindest nicht bekannt. Der C64 wäre der erste Rechner, der diese Maus-Geste beherrschen würde – sinnvoll fände ich sie aber durchaus für alle Rechner mit 2-Tasten-Mäusen ohne Scrollrad (z.B. ST oder Amiga). Man müsste das mal ausprobieren bei einem schon vorhandenen GUI oder Dummy.


    Zitat von ZeHa

    Naja letztendlich würde man ja in dem Moment mit der Maus keine andere Bewegung durchführen als wie wenn man einen Scrollbalken anpacken würde, was ja zuvor meist gemacht wurde (die Pfeile an der Scrollbar wurden ja eigentlich irgendwann von gar keinem mehr verwendet, so mein Eindruck). Nur dass man eben die Maus nicht erst zu einem etwaigen Scrollbalken bewegen müsste.

    Korrekt. Allerdings würde man (natürlich einstellbar) per Default in die andere Richtung schieben, weil man ja nicht den Scrollbalken anfasst, sondern das Dokument (welches sich ja gegenläufig bewegt). Ich denke, wenn sich der Mauspfeil dann in ein flaches "Patschehändchen" ändert, wird das noch klarer.

    Zitat von Retrofan

    Meines Wissens gibt es das ja auch noch gar nicht – ist mir zumindest nicht bekannt. Der C64 wäre der erste Rechner, der diese Maus-Geste beherrschen würde

    RISC OS hat sowas ähnliches: Wenn man einen Scrollbalken nicht mit der linken, sondern mit der rechten Maustaste draggt, scrollt man nicht in einer, sondern in zwei Dimensionen.

    Zitat von Mac Bacon

    Wenn man einen Scrollbalken nicht mit der linken, sondern mit der rechten Maustaste draggt, scrollt man nicht in einer, sondern in zwei Dimensionen.

    OK, aber nichts mit 2 Tasten gleichzeitig und man muss immer noch in den Scrollbalken klicken, korrekt?

    Zitat von darkvision

    Könnte man da nicht so was wie einen Programmierwettbewerb draus machen? Jetzt nicht für das gesamte OS, aber z.B. die kleinste Routine um die Oberfläche zu zeichnen.

    Zitat von Retrofan

    Einige davon gibt es sogar schon, nur nicht hier gesammelt, wie z.B. sehr schnelle Routinen zum Zeichen von Linien/Flächen und zum Bitmap-Scrollen. Eine weitere, noch zu erstellende, könnte eine proportionale Font-Zeichenroutine sein.

    Die Entwicklung einer solchen habe ich versucht., in diesem Thread anzustoßen und unsere Mitforisten 5ace und TD1334 haben daraufhin angefangen, coole Font-Render-Engines zu schreiben – sogar (im Falle von TD1334) inkl. einiger Grafik-Primitives (Linie, Rechteck, Scrolling ...), die man für die Entwicklung eines GUIs essentiell benötigt.


    Zitat von Retrofan

    Mal etwas ganz anderes: In einem anderen Thread habe ich darüber nachgedacht, ob man mit einer normalen 2-Tasten-Maus, wie der 1351, auch Scrolling (ähnlich einem Scrollrad) realisieren kann, ohne den Scrollbalken (bzw. Buttons) im GUI bemühen zu müssen. Meine Idee dazu ist, dass man innerhalb eines "Fensters" beide Buttons gleichzeitig drückt und dann die Maus bewegt, um den Inhalt zu verschieben. [...] Der Vorteil im GUI: man könnte vielleicht optional die Scrollbuttons weglassen und nur den Scroll-"Balken"/Index zeigen. Außerdem müsste man nicht extra dorthin steuern, sondern könnte (wie mit einem Scrollrad) direkt über einem Bereich mit dem Scrollen beginnen. Aber es ist mir auch klar, dass das bei längeren Scrollbereichen nicht mehr wahnsinnig komfortabel ist, weil man die Maus irgendwann neu ansetzen müsste (wenn man an der Tischkante ankommt) ...

    Ergänzung: Man muss noch nicht einmal die Maus neu ansetzen! Es reicht, wenn man die beiden Tasten loslässt und zwischendurch die Maus mal wieder hoch- (oder runter-) schiebt.


    Zitat von Retrofan

    Aber ich weiß nicht, ob diese Geste bei anderen Systemen evtl. schon anderweitig belegt ....

    Ergebnis: Ich habe nachgefragt, welche klassischen Systeme (der 80er) überhaupt (noch nicht einmal kombiniert) die 2. Taste nutzen – und bis aufs Amiga OS kann ich da Entwarnung geben. Die rechte Maustaste war vor Erfindung des zusätzlichen Kontextmenüs (Windows 95?) eher ein GUI-Stiefkind und wurde nur sporadisch verwendet. Man könnte also sogar bei einem GUI für den C64 das Scrolling allein auf die rechte Maus-Taste (plus schieben) legen – dass könnte halt nur im Vergleich/Wechsel zu heutigen Systemen etwas verwirren. Daher bleibe ich weiterhin ein Fan der 2-Tasten-Lösung.


    Alternativ: Analog zu Touch-GUIs könnte man auch darüber nachdenken, einen Scrollvorgang ganz ohne besondere Taste(n-Kombi) einzuleiten. Ein Klick plus darauf folgendes schieben innerhalb eines Scrollbereichs könnte das Scrollen auch auslösen. Nur muss dann halt eine Routine, die erkennt, ob jemand beim Anklicken eines aktiven Elements nur leicht verrutscht ist oder wirklich schieben will, etwas komplexer* sein. Wäre aber auch eine schöne Aufgabe. ;)


    *) Nach einem erkannten Klick (und evtl. umfärben eines aktiven Elements), müsste in kurzen Abständen (bis zum Loslassen der Taste) die Mausposition abgefragt werden. Wird ein Loslassen erkannt, sollte nochmal nach der Position gefragt werden und wenn sich der Pfeil weiterhin auf dem gleichen aktiven Element befindet, wird der (jetzt vollständige) Klick ausgewertet. Solange aber nicht losgelassen wird, wird die Mausbewegung als Scrollbewegung interpretiert.


    Was man noch überlegen könnte, ist, ob die Bewegung nach dem Loslassen der Taste(n) sofort gestoppt wird oder ob man eine gewisse "Kinetik" hinzufügt, die ein kurzes Weiterlaufen des Scrollbereichs ermöglicht.