Schade, ich versuche hier einen Konsens zu finden aber anscheinend bin ich der einzige. Wenn man eher die Unterschiede in den Ideen und Konzepten herausstellen will, bitte. Da kann ich auch mit leben.
Mit Geos ohne Turbo + externen Speicher zu arbeiten, macht keinen Spass. Das begreift jeder Geos Anwender nach 10 Minuten Anwendung...
[...]
Das System krankt nicht nur an der hässlichen Oberfläche, sondern auch an der Laufwerksverwaltung und an der Geschwindigkeit der Benutzeroberfläche.
[...]
Ich frage mich nur, ob es da nicht gleich besser wäre den Kram von Grund auf neu zu schreiben.
Ich gehe ja auch eher in die Richtung, dass man das komplett neu denken und sich vom bisherigen GEOS lösen sollte bzw muss. Nennen wir es einfach mal GEOS 4.0 oder gleich XYZ 1.0, über das wir hier sprechen. GEOS ist (bei 1 MHz) zu langsam, die Laufwerksverwaltung ist nix, die Bedienung ist outdated. Das kann ich alles (spätestens nach diesem Threadverlauf) unterschreiben.
Und natürlich benötigt das hier ausgedachte "GEOS 4.0" irgendwelche Zusatzhardware und würde auf einem Vannilla-C64 mit einer 1541 nicht gut laufen. Aber ich würde jetzt nicht gleich die teuerste der erhältlichen Erweiterungen als Minimalanforderung ansehen. So ein GEOS 4.0 sollte auch mit einem EasyFlash (kann ja vom TC64 und der 1541U emuliert werden) und einem SD2IEC als günstigem Massenspeicher schon toll laufen können. Und wer ein TC64 besitzt, für den läuft es dann noch toller.
anders herum wird ein Schuh daraus: Wir befinden uns auf einem 1-Mhz-Rechner mit 64KB, d.h. wir verwenden prinzipiell erst mal den Textmodus - und überlegen eventuell ob wir Hires brauchen.
Meinetwegen auch so. Ich bin da weit entspannter als manch anderer hier. Ich würde halt alle Modi unterstützen wollen und dann je nach Anwendung nutzen. Für einen Chat reicht sicher die 40-Zeichendarstellung des C64-Char-Modus, für einen Sprite-Editor eher nicht. Für einen Kernal mit Internetfunktion sollte es egal sein, in welchem Modus etwas angezeigt wird.
Das Beispiel mit dem Grafikprogramm diente dazu, zu zeigen, dass mir nicht nur der Darstellungs-Modus schnuppe ist (weil ich davon ausgehe, dass man ohnehin alle wichtigen unterstützen sollte, so wie es der C64 ja auch tut), sondern man sie sogar nach Belieben mischen kann. Und das Beispiel mit dem Tapecart-Browser sollte zeigen, dass ich auch gerne funktionale, wie ansprechende Interfaces im Char-Mode entwickle. Ich habe, glaube ich, schon jeden nativen C64-Darstellungs-Modus verwendet, inkl. ECM – eben je nach Anwendungsfall.
Ich hatte scherzhaft erwähnt, dass du einen Outlook-Klon entwickeln willst. Darauf bist du nicht eingegangen
Warum sollte ich? Ja, Outlook verwaltet auch Termine und Kontakte und man kann kommunizieren (ein PIM halt). Das ist es, was ich anfangs als möglichen Nutzwert für den alten C64 genannt habe. Wenn du magst, kann ich das hier nochmal bestätigen: Es scheint mir eine Möglichkeit zu sein, dem C64 ein 2. Leben zu schenken, so wie man andere alte Rechner als Homeserver einsetzt oder als Haushaltsbuch oder in der Küche, um Rezepte anzuzeigen.
Mir schwebt absolut nichts vor, was man auch nur annähernd als Productivity-Anwendung bezeichnen könnte
Gut, da gehen unsere Vorstellungen wirklich auseinander. Wobei man immer festhalten sollte, dass wir hier von "Productivity" in Anführungszeichen sprechen. Mir ist natürlich klar (und das habe ich mehrfach dargestellt), dass es immer auf den Goodwill des Anwenders, des C64-Fans, ankäme. Jedes heutige Gerät kann alles besser als der C64 – dass man ihn nutzt, hat nichts mit seinen "herausragenden" Fähigkeiten zu tun, sondern mit der "Liebe" zu den alten Kisten.
Ich persönlich würde halt lieber über Forum64-Status-Änderungen (jemand hat auf ihren Beitrag geantwortet ...) auf dem C64 informiert werden als auf dem Smartphone. Ich fände das halt cool – auch wenn ich verstehen kann, wenn die Mehrheit das lame findet.
Contiki ist m.W. in C geschrieben, selbst wenn sich der Code für den TCP-Stack weiter verwenden lässt, müsste man das erst mal für C64-ASM-Anwendungen ansteuerbar machen.
Mir scheint es, dass du gerne einen TCP/IP-Stack programmieren möchtest … dazu sage ich: Gerne, hau in die Tasten, den kann man sicherlich gut gebrauchen. Nicht nur für "GEOS 4.0". Du rennst bei mir offene Türen ein.
Vizawrite ist ein Geniestreich, irgendwelche WYSIWYG-Versuche wie Geowrite sind dagegen nur lachhaft.
Ich habe früher selbst mit Vizawrite geschrieben und fand es auch toll, dass der Pagefox-Editor sich daran anlehnt. Ich habe nichts gegen Vizawrite gesagt, nur dass es im 40-Zeichen-Modus arbeitet (was für eine Textverarbeitung halt eine gewisse Einschränkung darstellt).
Wer will heute schon Termine oder Kontake verwalten wenn man sie nicht möglichst einfach mit dem Mobiltelefon synchronisieren kann.
Da hast du nicht unrecht. Ich habe darüber auch schon nachgedacht (und bin zu keinen perfekten Lösungen gelangt). Aus dem C64 heraus bekommt man Termine und Kontakte sehr einfach mit einem kleinen Trick, den wir für unser Spiel Monster Buster XXL erdacht und umgesetzt haben: Generierte QR-Codes auf dem Bildschirm (VCards, iCal, URLs ...). Wenn man aber wirklich syncen will, muss man wohl mit einer kleinen Serveranwendung arbeiten. Entweder lokal auf dem PC im LAN (vielleicht mit einer OwnCloud-Erweiterung) oder über eine zukünftige C64-Cloud. 
Vielleicht ist aber auch der "C64-PIM im GEOS 4.0" etwas für die Leute, die ihre Daten lieber abgeschottet auf dem C64 aufbewahren wollen – unsere "Aluhüte" und Hitec-Verweigerer. Das könnte man ja mal diskutieren.
Je nachdem wie die Fenster gehandhabt werden.
Wheels öffnet Fenster über einem Anderen, somit muss ich sie verschieben um sie zu sehen.
Richtig. Deswegen würde ich auf dem kleinen Bildschirm des C64 auf überlappende Fenster verzichten. Da verschwendet man mehr Zeit mit dem Herumgeschiebe als man durch die Flexibilität der Fenster gewinnt. 1986 hat man das vielleicht noch nicht verstanden, 1993 (Apple Newton. Und in der Nachfolge PalmOS, iOS, Android) aber schon. Nur ist das halt nicht mehr bei GEOS (C64) angekommen, weil es nicht lange genug überlebt hat.
