letzter Beitrag von Retrofan am
Das sind nach wie vor sehr gefällige und tolle Entwürfe! 
Schade, dass das noch keine Umsetzung gefunden hat.
Gegenüber den frühen Screens ist die Titelleiste mit Seiten-Anzeiger und Dropzone nach oben gewandert.
Ich fand die alte Aufteilung etwas gelungener und stimmiger:
Jetzt wirkt irgendwie "alles nach oben gequetscht".
Ist aber wie immer Geschmackssache und keine Kritik an den tollen Mockups. 
Ich fand die alte Aufteilung etwas gelungener und stimmiger:
Jetzt wirkt irgendwie "alles nach oben gequetscht".
Es gibt natürlich Gründe, warum ich das verschoben habe. Im Ursprungsentwurf gibt es keine Namen für die Screens/Seiten, sondern nur den Seiten-Anzeiger und die Dropzone. Als ich dann den Screens Namen geben wollte, damit eine inhaltliche Sortierung vereinfacht wird und ich zudem darüber nachdachte, wie ich Ordner/Schrank-Inhalte darstellen will (nämlich mit dem Ordnernamen oben), habe ich den ganzen Kram nach oben geschoben. Titel/Ordner-Namen am unteren Rand wird niemand wirklich verstehen.
Ansonsten gebe ich dir recht – unten macht die Zeile einen schönen Abschluss und rückt den Inhalt in die Mitte. Aber Funktion vor Optik.
Ist aber wie immer Geschmackssache und keine Kritik an den tollen Mockups.
Kein Problem. Ich bin Profi und daran gewöhnt, dass meine Entwürfe diskutiert werden.
In welchem Format liegen die Ressourcen vor?
Wie fast immer bei mir: als PNG (auf Wunsch mit indizierten Farben in C64-Reihenfolge).
PNGs mit fixer C 64 Palette müssten wohl reichen.
1:1 Screens ohne CRT-Simulation/Mauszeiger, sowie eine Übersicht über alle GUI-Elemente, gebe ich direkt an ogd,
Falls möglich, bitte die PNGs so:
* Allles Bilder ohne Rand, also max. 320x200 Pixel
* Backdrops, Hires- und Sprite-Layer von Hintergründen zusätzlich als separate PNGs
* Dialoge freigestellt/gecropt, sprich ohne Hintergrund und in richtiger Grösse herausgeschnitten
Wenn das zu aufwendig sein siollte, nehme ich aber auch ein PSD im möglichst altem CS2-Format und schau mal, wie weit ich damit komme 
Für das Pulldown-Menü und Dialoge wird der Hintergrund dynamisch gepuffert.
Sind Dialoge statisch oder vom Benutzer verschieb- und in der Größe veränderbar, nachdem sie schon angezeiogt wurden? Und ganz allgemein gefragt: Gibt es GUI-Elemente, deren Breite/Höhe keine Vielfache von 8 Pixel sind? Jetzt mal von (proportionalen) Fonts abgesehen, wo die Glyphenbreiten natürlich unterschiedlich sind. Aber auch die haben dann alle eine Höhe von 8*n Pixel, oder?
Der Text-Editor ist nichts, was man heutzutage umsetzen sollte.
Also ein Minimal-Editor/-Reader sollte schon drin sein.
* Allles Bilder ohne Rand, also max. 320x200 Pixel
* Backdrops, Hires- und Sprite-Layer von Hintergründen zusätzlich als separate PNGs
* Dialoge freigestellt/gecropt, sprich ohne Hintergrund und in richtiger Grösse herausgeschnitten
Kein Problem. Ich muss allerdings einschränken, dass evtl. nicht alles ad hoc verfügbar ist, weil ich natürlich so spontan nicht darauf eingestellt war, alles für eine Umsetzung parat zu haben. Bis jetzt waren es ja nur Mockups, die die grundsätzlich Optik und Funktionalität andeuten sollten. Aber ich bastele daran.
Sind Dialoge statisch oder vom Benutzer verschieb- und in der Größe veränderbar, nachdem sie schon angezeiogt wurden?
Sie sind statisch. Und wie gesagt: klassische Fenster gibt es nicht. Das GUI orientiert sich eher an "Mobile-GUIs" denn an Windows und Co.
Gibt es GUI-Elemente, deren Breite/Höhe keine Vielfache von 8 Pixel sind? Jetzt mal von (proportionalen) Fonts abgesehen
Da fallen mir keine ein.
Aber auch die haben dann alle eine Höhe von 8*n Pixel, oder?
Korrekt. Sie stehen nur nicht immer direkt in einer Char-Zeile. In manchen Bereichen haben wir 16 px Höhe und da ist dann Text vertikal mittig platziert. Ich glaube, Hexworx hat in seiner Text-Render-Engine dann "einfach" die Zeilenhöhe verdoppelt.
Also ein Minimal-Editor/-Reader sollte schon drin sein.
Richtig. Nur zeigt mein Mockup halt einen Wysiwyg-Editor mit unterschiedlichen Fonts unterschiedlicher Größe etc. (halt wie bei GEOS). Ich würde aber heutzutage eher einen schlankeren Markdown-Editor bevorzugen.
Apropos Text: Vorgesehen war/ist die standardmäßige Unterstützung von ISO-Encoding statt PETSCII. Dafür habe ich auch schon Fonts (auch wieder als PNG, ich habe aber einen Fontkonverter) vorbereitet. Ich weiß nur (noch) nicht, ob es genau die sind, die ich in den Mockups verwendet habe.
Ich muss allerdings einschränken, dass evtl. nicht alles ad hoc verfügbar ist
Mach die keinen Stress deswegen. Ein paar "saubere" PNGs ohne PAL-Artefakte reichen fü den Anfang.
Apropos Text: Vorgesehen war/ist die standardmäßige Unterstützung von ISO-Encoding statt PETSCII. Dafür habe ich auch schon Fonts (auch wieder als PNG) vorbereitet. Ich weiß nur (noch) nicht, ob es genau die sind, die ich in den Mockups verwendet habe.
Ein visueller Prototyp hat ja wenig bis gar keine richtige Funktionalität. Ich denke fürs Erste reichen dafür auch vorgezeichnete Bildausschnitte. Fontdateien fürs Textrendering braucht man erst später.
Ein paar "saubere" PNGs ohne PAL-Artefakte reichen fü den Anfang.
OK
Vorher will ich aber noch ein paar Sachen aktualisieren. Hier ist der letzte Stand der 2-Tafel-Ansicht im Files-Tab. Ich habe hier auch die Tabulator-Ansicht geändert, weil sie so nicht mehr direkt an der Tab-Fläche hängt und dadurch bei den Farben davon unabhängiger wird. Links neben den Tabs findet man die Darstellungs-Optionen, rechts davon die Werkzeuge Rename/Delete/New-Folder/Add-to-AppsTab. Diese werden nur aktiv (weiß) gezeigt, wenn sie nutzbar sind. Ansonsten sind sie hellblau. Edit wäre also eigentlich nur aktiv, wenn man nur eine einzelne Datei ausgewählt hat.
Die beiden Pfeile (kopieren/verschieben) zwischen den Tafeln sind dynamisch. Ohne Datei-Auswahl sind sie nicht sichtbar. Wählt man Dateien auf einer Tafel aus (gelb hinterlegt), werden die Pfeile in Richtung der anderen Tafel gezeigt.
Und hier sieht man den Apps-Tab mit der neuen Tab-Leiste und einen Ordner/Schrank-Inhalt – mit Zurück-Button. Diese ganzen Buttons sind übrigens 2x2-Chars groß, sie sehen nur kleiner aus.
NetChess bitte dann als erstes umsetzen
NetChess bitte dann als erstes umsetzen
Da kann ich leider auch nur mit der Grafik helfen:
Das Gute gegenüber klassischen C64-Schachprogrammen wäre halt, dass man keine eigene Schach-KI benötigt, weil die Gegner echte Spieler im Internet wären. Ich hoffe, das das Protokoll den C64 nicht vor unüberwindbare Hürden stellen würde. (Ein bisschen stolz bin ich auf meine gut identifizierbaren Schachfiguren – die meisten anderen auf dem C64 finde ich nur mäßig gelungen)
Retrofan müsste ein NaxOS-"Manifest" schreiben, wo in wenigen Worten mal die hier genannten Eckdaten zusammengefasst sind, und in seine Signatur packen.
Das kann ich mal machen, damit man nicht so oft alles wiederholen muss. Dann verweist man auf das Dokument und gut isses.
Existiert so ein Dokument schon?
Vorher will ich aber noch ein paar Sachen aktualisieren. Hier ist der letzte Stand der 2-Tafel-Ansicht im Files-Tab. Ich habe hier auch die Tabulator-Ansicht geändert, weil sie so nicht mehr direkt an der Tab-Fläche hängt und dadurch bei den Farben davon unabhängiger wird. Links neben den Tabs findet man die Darstellungs-Optionen, rechts davon die Werkzeuge Rename/Delete/New-Folder/Add-to-AppsTab. Diese werden nur aktiv (weiß) gezeigt, wenn sie nutzbar sind. Ansonsten sind sie hellblau. Edit wäre also eigentlich nur aktiv, wenn man nur eine einzelne Datei ausgewählt hat.
Ich finde deine Entwürfe wirklich genial. Sie sind absolut durchdacht, zeigen eine saubere GUI und orientieren sich als willkommene Abwechslung vor allem nicht an Windows (viele andere C64-GUIs machen aus mir nicht erfindlichen Gründen den Windows-Start-Button nach). Aber das Beste: Man versteht deine GUI ohne Erklärungen. Genauso soll es ja eigentlich sein, egal ob auf Apple, PC oder am C64.
Existiert so ein Dokument schon?
Leider nein.
Ich finde deine Entwürfe wirklich genial.
Vielen Dank. Bevor ich angefangen habe, irgend etwas zu pixeln, habe ich mir ja auch schon einiges an Gedanken zum Thema gemacht. Wie du schon sagst, soll ein GUI die Benutzung eines Computers erleichtern und nicht komplizierter machen. Und ich liebe es, Dinge einfacher zu machen.
Ich bin immer noch dabei, das Interface zu zerschneiden, weil mir immer wieder was dazwischenkommt und mir beim wiederholten angucken auch immer noch kleine Verbesserungen einfallen. Also bitte etwas Geduld.
----
Was ich aber grundsätzlich mal sagen will, weil es ja auch viele andere Ansätze für neue C64-GUIs oder -OSs gibt (und gab):
Was ist denn das Ziel eines neuen grafischen Betriebssystems? Natürlich will man die Bedienung des C64 verbessern. OK, allerdings macht das natürlich nur für die Nutzer Sinn, die mit dem C64 mehr machen wollen, als nur Spiele zu starten – denn App-Launcher gibt es ja schon (z.B. der Launcher vom EasyFlash aber auch für jeden anderen Massenspeicher).
Wir haben also als Zielgruppe die C64-Poweruser und die, die gerne mehr mit ihrem C64 machen wollen, als nur Spiele zu starten. Das ist natürlich eine kleinere Zielgruppe – dass muss klar sein. Wenn es also nicht in erster Linie darum geht, Bestandssoftware zu starten (denn dafür gibt es Lösungen) – was ist dann das Ziel eines neuen (grafischen) Betriebssystems?
Meines Erachtens sollte ein neues OS neue Möglichkeiten eröffnen, die es zuvor nicht gab. Nur so kann man Entwickler finden, die bereit sind, das OS als Basis für neue Programme zu verwenden. Auf der Basis kann man dann verschiedenen Lösungen oder Ideen diskutieren.
Z.B. Multitasking: Das wird bei einigen alternativen C64-Betriebssystemen als Key-Feature angesehen. Aber ist das eine nützliche Funktion für Entwickler und User? Was will man auf dem C64 alles gleichzeitig laufen lassen? Wo sind die Grenzen bei 1 MHz? Klar, 16 Tasks, die nichts tun, kann man schön mal starten – aber lass da mal wirklich was drin laufen – dann wird das 1 MHz auf diverse Tasks aufgeteilt und dann wird man sehen, wie schnell das noch ist. Dazu kommt der enge Speicherplatz beim C64 – wieviele Programme will man denn im Speicher halten? Ganz ehrlich – ich sehe das als coole Demo an (guck mal, der C64 kann "Unix") – aber wirklich nutzbar ist das meines Erachtens nicht. Und es eröffnet halt auch keine neuen Möglichkeiten. Um das Multitasking nutzen zu können, müssten Programme daran angepasst sein – aber jedes einzelne Programm profitiert vom MT erst einmal nicht. Also warum sollte jemand dafür ein Programm schreiben?
---
So, aber nun zu dem hier diskutierten System – was soll das können, was andere nicht können?
Über die Zeit haben wir ja einige gute Ideen gesammelt und integriert. Erst einmal ist ja auffällig, dass das GUI, wie GEOS/MP3, Bitmap-orientiert ist. Aber was bringt das? Nun, meines Erachtens bringt das vor allem zusätzliche Arbeitsfläche, weil man mit schmaleren Proportionalfonts arbeiten kann. Und beim C64 ist "Fläche" echt Mangelware. In Chars gerechnet haben wir beim C64 nur 40 Zeichen pro Zeile. Das ist eher wenig – und für manche Anwendungen ZU wenig. Mit Bitmap können wir aus dem starren Raster ausbrechen und 60 bis 80 Zeichen pro Zeile darstellen. DAS kann machmal schon DEN Unterschied machen, bei einem Text-Viewer oder Zweitafel-Verzeichnis-Ansichten zum Beispiel. OK, Bitmap hat Vorteile – aber warum darauf ein GUI/OS basieren lassen? Nun, weil es damit für Dritte einfach wird, diesen Modus zu nutzen (der sonst sehr oft brach liegt). Wenn man Ein- und Ausgabe-Routinen zur Verfügung gestellt bekommt, schnelles Scrolling, Grafik-Darstellung, Icons usw. dann kann man auf der Basis schnell ein neues Programm entwickeln, dass von den Features profitiert. Und da wollen wir ja hin.
OK, aber Bitmap alleine kann es doch nicht sein, oder? Nun ja, indirekt bekommen wir darüber (neben mehr "Fläche") weitere Features: Zeichensätze können die vollen 256 Plätze nutzen, weil man keine invertierten oder GUI-Zeichen mitschleppen muss. Baut man ein UI im Charmode, kommt man nur schwer drum herum, invertierte und normale Chars zu mischen – und zusätzlich verbraucht man Zeichen für GUI-Elemente. Dann werden aus den 256 möglichen Zeichen erst 128 und dann ca. 100. Da hat man dann eine ASCII-Untermenge ohne irgendwelche internationalen Sonderzeichen und vor allem ohne jeglichen modernen Standard. Bei Bitmap-Darstellung können wir auf die vollen 256 Zeichen zugreifen und das auch noch ISO-Standard-konform (oder meinetwegen auch CP-1252). Das spart Konvertierungen und es ermöglicht, direkt internationale (z.B. deutschsprachige) PC-Texte darzustellen.
Das ist schonmal ganz schön und bringt konkrete Vorteile gegenüber dem Standard-C64 und vielen anderen OS-Ansätzen. Kann Bitmap-Text-Darstellung noch mehr? Ja, man kann jederzeit den Font wechseln, ohne zuvor geschriebenes zu verändern. Man kann also Schriften mischen, z.B. normal und kursiv oder normal und fett oder sogar Fonts mit unterschiedlichen Zeichenvorräten und Encodings. Also z.B. ein Interface mit schmalem ISO-Zeichensatz mit einem File-Selector, der original PETSCII darstellt. GLEICHZEITIG und das sogar ohne zusätzlichen Speicherverbrauch, weil man mit nur jeweils einem geladenen/geswitchten Zeichensatz arbeiten kann.
Ok, wir haben also bei Bitmap-Darstellung mehr "Fläche" (durch schmalere Schrift), multiple Zeichensätze und standard-konformes internationales Encoding. Zusätzlich würde das GUI bestimmte Routinen für Textfelder, Input-Felder, Buttons, Tabs, Tool/Icon-Leisten usw. zur Verfügung stellen. Darauf basierend könnte man sich doch schon neue Anwendungen vorstellen:, z.B. ein PC-kompatibler Markdown-Texteditor (mit mehr als 40 Zeichen pro Zeile), der direkt PC-Texte von der SD-Karte öffnen kann und vielleicht sogar die eine oder andere Textauszeichnung darstellt. Oder ein Browser – dazu später mehr.
Im Bitmap-Mode kann man auch sehr leicht Schrift und Grafik mischen, was große Icon-Darstellungen erlaubt, wie man sie von den meisten App-Launchern und Desktops so kennt. Das wird als sehr attraktiv und übersichtlich empfunden. Aber es ermöglicht natürlich auch die Entwicklung von Grafikprogrammen, vor allem, wenn das OS eine Möglichkeit zur Verfügung stellt, per Raster-Interrupt den Grafik-Modus (z.B. auf Multicolor) vertikal umzuschalten.
Noch ein letztes Wort zur Bitmap-Darstellung: Ja, sie ist langsamer als der Charmode (bietet aber mehr Möglichkeiten). Aber ist Bitmap so langsam, wie man es vom alten GEOS kennt? NEIN! In diesem Thread und auch in anderen wurde schon mehrfach gezeigt, dass Bitmap-Darstellung auch schneller geht, als man denkt. Zeichenroutinen für Punkte/Linien/Flächen (darauf basiert ein GUI) können 4 Mal (!) so schnell sein, wie bei GEOS. Auch die Textdarstellung kann beschleunigt werden und vor allem auch das Scrolling – bis hin zu Geschwindigkeiten, bei denen man beim Lesen kaum noch hinterher kommt.
----
Aber reicht das schon, um wirklich Nutzer und Entwickler anzulocken? Nun, ein OS sollte sich nicht auf eine neue/alternative Darstellungsweise alleine verlassen – dann wäre es ja auch nur ein GUI. Genau so wichtig finde ich die Unterstützung "moderner" C64-Erweiterungen, vor allem Massenspeicher, wie dem SD2IEC oder RAM/ROM-Speichererweiterungen, wie REU oder EF. Letzteres ermöglicht sogar ein komplett geändertes Speichermanagement. Damit erweitert man wirklich die Fähigkeiten des C64. Die Verwaltung eines erweiterten Speichers sollte das OS übernehmen und dem 3rd-Party-Entwickler die Nutzung vereinfachen.
Was aber meines Erachtens auch unter moderne Erweiterungen fällt, ist die (W)LAN-Anbindung und damit letztendlich auch der Internet-Zugang. Die Unterstützung einer solchen Hardware durch das OS wäre meines Erachtens ein Game-Changer, was die Anwendungs-Entwicklung auf dem C64 anginge. Nicht nur sowas, wie C64-Chat/Messenger/Online-Play wäre damit denkbar, auch ein (Proxy-unterstützter) reduzierter Webzugriff oder die Uhrzeit/Datum-Abfrage (erspart die Echtzeit-Uhr) oder ein App-Store oder "Direkt-Start" von Demos/Games aus der CSDB heraus – nein, man könnte sogar benötigte Rechenpower auslagern und z.B. serverunterstützte Berechnungen durchführen (in meinem GUI-Mockup soll das Mandelbrot-App-Icon einen Hinweis darauf geben) – Grafik-Konvertierungen, 2D/3D-Renderings usw. – alles, bei dem der Output-Download schneller geht als die Berechnung direkt auf dem C64.
Aber man muss auch gar nicht nur das Internet als Erweiterung bei einem LAN-Zugriff sehen. Man könnte z.B. auch auf Netzwerk-Drucker zugreifen, statt aufwändig zu versuchen, Drucker direkt an den C64 anzuschließen. Natürlich würde auch das File-Sharing zwischen PC und C64 vereinfacht werden – Man hätte dann so eine Art C64-Dropbox für den Datenaustausch.
---
So, dann hätten wir also 4 Säulen, auf denen das OS aufbauen würde: Bitmap-Darstellung vor allem (aber nicht nur) für besseres Text-Rendering, GUI-Toolbox für schnelle UI/Formular-Entwicklung, Unterstützung von modernen (Massen-) Speicher-Lösungen und als Sahnehäubchen ein (einfach zu nutzender) LAN/Online-Zugang. Ich denke, dass das die Möglichkeiten eines C64 so sehr verändern und erweitern könnte, dass das OS wirklich auf ein erhöhtes Interesse bei Usern, wie auch bei Entwicklern, stoßen könnte. Man könnte halt ganz neue Sachen denken und machen – auf fast der gleichen Hardware, auf der das früher nicht ging.
Und das ist halt ein Unterschied zu vielen anderen Ansätzen – die nicht wirklich neue Möglichkeiten schaffen, sondern eher in sich geschlossene Tech-Demos darstellen.
Gerne würde ich dazu weitere Meinungen hören ...
Was aber meines Erachtens auch unter moderne Erweiterungen fällt, ist die (W)LAN-Anbindung und damit letztendlich auch der Internet-Zugang. Die Unterstützung einer solchen Hardware durch das OS wäre meines Erachtens ein Game-Changer, was die Anwendungs-Entwicklung auf dem C64 anginge.
Einen Internetzugang sehe ich auch als einen sehr wichtigen Punkt eines neuen OS an. Das eröffnet so viele neue Möglichkeiten, den C64 zu nutzen, wie sonst kein anderes Feature.
Was ich noch vergaß: Man sollte ein neues OS auf jeden Fall auf eine OpenSource-Basis stellen. Zum einen braucht sich dann niemand Sorgen machen, dass es technische oder rechtliche Behinderungen gibt (wie der Kopierschutz und die Rechteprobleme beim original GEOS), zum anderen kann man dadurch hoffen, dass selbst bei einem Ausfall (Krankheit, Tod, Zeitmangel, Lustmangel) des Hauptentwicklers die Weiterführung des Projekts nicht automatisch gestoppt ist.
Man sollte ein neues OS auf jeden Fall auf eine OpenSource-Basis stellen.
Na ja, das ist ja immer noch die Entscheidung des/der Entwickler.
Mir wäre das ziemlich egal. Die meisten Spiele, die neu für den C64 rauskommen, sind CloseSource. Wieso sollte das dann bei einem OS "unbedingt" anders sein?
Für ein gutes neues C64-OS (evtl. sogar auf Modul) wäre ich jedenfalls auch bereit, einige Euros dafür auf den Tisch zu legen, wenn es so "das Licht der Welt" erblicken könnte.
Wieso sollte das dann bei einem OS "unbedingt" anders sein?
Er hat die Gruende doch genannt 
Die meisten Spiele, die neu für den C64 rauskommen, sind CloseSource. Wieso sollte das dann bei einem OS "unbedingt" anders sein?
Die meisten C64 Spiele sind mit Version 1.0 oder 1.0.1 fertig entwickelt. Da muss man sich um einen Fortbestand keine Sorgen machen. Bei einem OS wünscht man sich evtl., dass z.B. auch zukünftige Hardware-Erweiterungen eingebunden werden – Und wenn zwischenzeitlich der Entwickler verstorben ist oder sich ein anderes Hobby gesucht hat, dann wäre es für andere Entwickler halt einfacher, auf einen (wenn auch nur mäßig) kommentierten Ur-Assembler-Code zurückgreifen zu können, als einen Disassembler (wie bei GEOS geschehen) anwerfen zu müssen.
Außerdem sagte ich "man sollte ...", wäre also mein Wunsch oder Empfehlung. Wenn ein Entwickler so etwas umsetzen will, dann macht er es natürlich, wie er will.
Für ein gutes neues C64-OS (evtl. sogar auf Modul) wäre ich jedenfalls auch bereit, einige Euros dafür auf den Tisch zu legen
Das wäre komplett unabhängig von der Lizenz zu sehen. Natürlich kann man auch für OpenSource-Entwicklungen Geld verlangen. Ich würde sogar überlegen, ob es nicht eine gute Idee wäre, ein Kickstarter-Projekt o.ä. davon zu machen, sobald man etwas lauffähiges vorzeigen kann. Wenn dann vielleicht 100 Leute bereit wären, z.B. je 50 € zu bezahlen, dann hätte der Programmierer zumindest 1 bis 2 Monate Arbeit bezahlt bekommen – auch wenn wahrscheinlich mehr Arbeit drinstecken würde.
Eine andere Idee war es mal, ob man nicht eine neue Speicherlösung (also Hardware) entwickeln könnte, auf die das neue OS maßgeschneidert wäre und dann mitgeliefert (also mitverkauft) wird.
Was ist denn das Ziel eines neuen grafischen Betriebssystems? Natürlich will man die Bedienung des C64 verbessern. OK, allerdings macht das natürlich nur für die Nutzer Sinn, die mit dem C64 mehr machen wollen, als nur Spiele zu starten – denn App-Launcher gibt es ja schon (z.B. der Launcher vom EasyFlash aber auch für jeden anderen Massenspeicher).
Für so etwas bin ich ganz Feuer und Flamme!
Für mich ist die erste zentrale Anwendung des UI der Filebrowser. Und obwohl es da, wie du schreibst, viele App-Launcher bereits gibt, gibt es keinen, der alles kann. Mich persönlich nervt es, dass ich App-Launcher A für Hardware A nehmen soll, App-Launcher B für Hardware B. App-Launcher C funktioniert nur mit einem Trick mit Hardware A und unterstützt wesentliche Funktionen nicht und App-Launcher D wäre ein wenig großzügiger, verursacht aber Augenkrebs.
Ich hätte gern einen Filebrowser, der für all die Hardware da draußen da ist. Der als GUI durchdacht ist und entsprechend gut ausschaut (und das tut er, wenn du ihn designst!), der alle Funktionalitäten aufweist, die man braucht. Also eine zentrale und bequeme sowie elegante Anlaufstelle für alles, statt wie bisher das Gefrickel. Ich möchte moderne Hardware wie Ultimate II+, EasyFlash3 oder SD2IEC genauso (nativ - also direkt, auch ohne D64-Emulation) unterstützt sehen, wie "alte" Hardware (CMD HD, RAMLink, FD oder 1581, 1571 und 1541). Ebenso REU, SuperCPU und TurboChameleon. Ich möchte Vorschaufunktionen haben für Text, Grafik (alle möglichen Formate) oder .sid-Tunes. Kopieren, verschieben, löschen, mit Partitionen und Unterverzeichnissen arbeiten und ja, auch dann und wann mal eine Software starten. Das wäre für mich DER Traum.
Bei all den anderen Dingen, die du anführst (grafische UI, Internet, Open Source, vielleicht sogar Kickstarter), bin ich auf jeden Fall dabei!
