Nein. Vorschläge?
Wie sieht es aber mit einer Menüleiste wie beim alten MacOS aus. Wäre schön, wenn sich alle OS-Apps an diese "Vorgabe" halten würden: Links ein Button (z.B. "Go") zum Anzeigen eines GoDos Infoscreen, zum Anzeigen eines Infoscreen zur aktuell laufenden OS-App, zum beenden der App, und zum starten einer beliebigen anderen OS-App (das schließt natürlich auch die gerade laufende App); Ganz rechts eine Uhr (ohne Sekunden - wir wollen ja nicht die geballte CPU-Power für die Sekundenanzeige verballern ); Dazwischen ein App spezifisches Menü. Wäre so etwas (ohne zu viel Aufwand) möglich? Nachteil wäre natürlich, dass alle Apps eine Zeile weniger Platz haben.
Ich mag Menüleisten, wo immer alles an seinem Platz ist und man nicht suchen muss egal in welchem Programm man gerade ist. Dazu finde ich einen "Startbutton" sehr praktisch, über den man z.B. Programme startet. Da wir nicht über ein Multitasking OS sprechen, brauchen wir keine Startleiste, um laufende Programme zu sehen und zwischen ihnen zu wechseln. Ich fände die Kombination von beidem jetzt gar nicht schlecht. Das muss dann natürlich eine Funktionalität sein, die das OS den OS-Apps zur Verfügung stellt. War halt nur mal so ne Idee genau wie das integrieren einer Uhr.
Zugang zum Netz
Sowas? Bitte melde dich an, um diesen Link zu sehen.
Zugang zu Sensoren
Extrem unnütz bei einem stationären Computer aber ich find es extrem cool:
Bitte melde dich an, um diesen Link zu sehen.
Retrofans CPU Temperatur fand ich extrem witzig! Es hat sofort ein "Das ist so unnütz, dass ich es haben muss"-Gefühl ausgelöst. Spontan würde ich das über einen Sensor an der Joystickbuchse (Paddle-Eingang) lösen wollen. Ich habe mich aber noch nie wirklich mit so Temperaturfühlern auseinander gesetzt.
Zugang zu *Aktoren*
Zählt sowas auch dazu?
Bitte melde dich an, um diesen Link zu sehen.
Und TSB: Verstehe ich das richtig, es soll dazu dienen, goDos direkt zu programmieren? Ich dachte da eher an sowas wie einen APP-Builder, also ein TSB-*Programm*, das all die lästige Arbeit verkürzt, die ein Coder sonst tun müsste. Man bastelt sich im Builder eine Oberfläche und der Builder füllt den dazu erforderlichen Code gleich mit rein. Das, was die APP dann spezifisch machen soll, ist aber wieder Aufgabe des Coders. Es gibt für Spezifisches ja keine Bausteine. Der Builder liefert also irgendwann Quellcode, das Gerüst für die endgültige APP. - Soll das so sein? (Das kann ich mir vorstellen.) Oder anders? Dann: wie anders?
Auch ich weiß nicht genau, ob ich dich richtig verstehe. Deine Beschreibung klingt irgendwie ein bisschen nach VB.
An einen Builder hatte ich noch gar nicht gedacht. Meine Vorstellung war bisher so, dass es zusätzliche Befehle geben sollte wie "button", "radiobutton", "checkbox", "menubar", "menuitem", "infobox", "filedialog", ..., die halt dem Look von goDos entsprechen. Außerdem sollten die Programme nach dem Compilieren nativ unter goDos laufen, ohne dass man erst noch TSB oder irgend etwas anderes von Hand laden muss. Bei Diskettenbetrieb müsste man damit leben, dass goDos die Laufzeitumgebung automatisch nachläd. Besser wäre es natürlich mit einem Modul. Ob die Befehle jetzt durch das OS zur Verfügung stehen (so DLL mäßig) oder ob der Compiler den entsprechenden Code für diese Funktionen dazu packt, wäre mir vollkommen egal. Ein Builder für die App-UIs wäre natürlich noch einfacher aber der müsste ja auch erstmal programmiert werden.
Hier ist aber wirklich die Frage, ob der Nutzen den Aufwand rechtfertigt. Ich fänd es endgeil und hätte voll Spaß meine alte Adressdatenbank neu zu schreiben und eine goDos-App zur Steuerung eines SVI-2000 Roboterarms und so unnützes Zeug. Ein Minesweeper für goDos hätte ich wahrscheinlich auch schnell! Ich weiß aber nicht, ob es noch mehr so Spinner wie mich gibt, die in BASIC direkt am C64 programmieren wollen?!