letzter Beitrag von Retrofan am
Es ist halt was dazwischen und vielleicht fände das der eine oder andere ganz gut.
Na, dann oute ich mich mal und sage:
Ich finde die Idee echt nett. Da kommt doch auch beim Entwickeln ein klein wenig 8-Bit-Feeling (RETRO!!!) auf.
Und deswegen sind wir doch alee hier, nicht wahr 
Editor abgelehnt, weil z. B.:
Eine Seite rendern darf ja ruhig nen Moment dauern. Lag beim Tippen ist aber ein KO kriterium.
Text-Eingaben wird es ja zwangsläufig geben müssen. Dann aber wohl (zunächst) auf ein Feld/eine Zeile beschränkt. Hab ich mich jetzt aber auch noch nicht näher mit beschäftigt. Stellt aber grundsätzlich kein riesiges Problem dar. Etwas Lag wird es da sicher geben, aber das wird man vermutlich kaum merken. Aber ein Fullscreen-Editor? Das wird nix.
Und dieser 'Editor' wäre zudem auch schon ein zusätzliches Mörder-Projekt. Ich glaub, das braucht's auch nicht.
Man erweitert das C64-Basic oder vielleicht sogar Basic 7.0 (C128) oder irgendeinen anderen Dialekt und erweitert den um einige NaxOS-spezifische Befehle (z.B. zum Aufrufen der GUI-Routinen).
Die BASIC-Erweiterung heißt einfach 'SYS,x,y,tx$' oder ähnliches. Angedacht hatte ich eine BASIC-Anbindung auch schon. Zum Teil daher hatte ich schon eine Sprungtabelle für so manche Sachen auch schon eingebaut.
Aber wenn man z.B. Basic auf dem C64 programmieren möchte, muss normalerweise das Basic-Rom eingeblendet sein.
Und selbst auch noch, wenn man das durch einen Compiler jagt.
-> Eine Frage dazu nebenbei an alle: Beispiel BASIC-BOSS: Gibt es evtl. schon einen Hack, wo man den BASIC-Start bzw. eben das ganze Kompilat woanders hinlegen kann? Ist vielleicht ganz simpel, hab aber noch nicht reingeguckt.
Eine Sonderbehandlung benötigt evtl. (wenn man es schnell haben will) der Rand von Dialogen (z.B. File-Requester). Dieser besteht zur Hälfte aus der voreingestellten Dokumentenfarbe (also fast immer hellgrau) und zum anderen aus der Dialog-Hintergrundfarbe. Er dient dazu, einen optischen Abstand von Dialog und dahinter liegender Ebene zu bilden.
Was ist der Unterschied zwischen 'Dokumentenfarbe' und 'Hintergrundfarbe'? Was ist die "Hälfte vom Rand von Dialogen"? Soll der außen rum um den Dialog? Soll der dann leer sein/gelöscht werden bei Aufruf des Dialogs? Soll der Rand dann ein wirklich gemalter Rand sein? Einfach so ein Trauer-Rand z. B.? Soll der auf diese Außenlinie oder nur auf dem eigentlichen Rand des Dialogs (was optisch auch möglich wäre, da bei der Ausgabe eh immer 2/3 Pixel Rand berücksichtigt werden sollten und so Luft dafür wäre).
Zeig doch einfach mal ein Mock-Up davon. Die kann ich meist besser lesen, als deine Texte 
.
Vorzeigbares habe ich die Tage nicht vollbracht. Hab mir nur erstmal ein paar Gedanken/etwas Aufschrieb zu den Icons/Programm-Header ( 
GoDot...) etc. gemacht. Die Icons müssen ja vom Programm mitgebracht werden, also Pixel + Farben (9 Byte/18 Byte?). Wie ist es schnellstmöglich zeichenbar? Hab mir erstmal das simple 'New Folder'-Icon nachgebastelt und teste nun damit rum.
Bis denn.
Aber ein Fullscreen-Editor? Das wird nix. Und dieser 'Editor' wäre zudem auch schon ein zusätzliches Mörder-Projekt. Ich glaub, das braucht's auch nicht.
War ja eh nur eine spinnerte Idee. Ich war davon ausgegangen, dass man das auf Basis eines irgendwann erscheinenden ASCII/ISO-Texteditors baut.
Und selbst auch noch, wenn man das durch einen Compiler jagt.
Edit: Bei meinem ersten Antwortversuch hatte ich mich selbst ausgetrickst. Ich gehe bei der "Compiler-Farm" davon aus, dass man nicht das Rom-Basic verwendet, sondern ein eigenes, dass aber ähnlich zum Original ist (um den Einstieg zu erleichtern). Deswegen sprach ich auch beispielsweise von Basic 7.0 (mit zusätzlichen Erweiterungen) als Basis, obwohl der C64 ja nur Basic 2.0 eingebaut hat. Es könnte auch Pascal, C oder Java sein.
Was ist der Unterschied zwischen 'Dokumentenfarbe' und 'Hintergrundfarbe'? [...] Zeig doch einfach mal ein Mock-Up davon.
Habe ich doch schon. Der File-Requester ist ein Dialog und da habe ich die am Rand liegenden "Chars" zur Hälfte mit Dialog-Hintergrundfarbe und zur Hälfte mit der Dokumenten-Farbe des darunter liegenden Layers gefüllt. In diesem Fall ist aber der Zusatz "Dialog-" der wichtige Unterschied, nicht der Begriff "Hintergrund". Die "Dokumentenfarbe" kann ein App-Autor evtl. selbst bestimmen und ist per default hellgrau. Das ist die vorherrschende Farbe für den Hintergrund – bei einem Texteditor oder der Home-App ist das hellgrau und bei einem Astronomieprogramm könnte es schwarz sein und bei einem Roulette-Spiel wäre es wahrscheinlich grün (auch wenn einzelne Blöcke (z.B. des Interfaces) evtl. eine andere Background-Color haben).
(Edit: Ich habe den Satz über den "Hintergrund" neu formuliert)
Wenn du jetzt Neues OS/GUI für den C64 meinst, dann hab ich es wohl verstanden (hoffe, das Bild wird angezeigt):
Sehr hübsch, keine Frage. Die besondere Darstellung war mir bislang gar nicht aufgefallen.
Bedingt natürlich wieder eine Sonderbehandlung/gesonderte Routine. Machbar: Klar. Wie: Noch keine Ahnung. Sind im Grunde aber ja nur 8 PETSCII-ähnliche Zeichen, die drum-rum gemalt werden müssen. Ich muss mir eh noch für die 'Fenster'/Dialoge was ausdenken. Da ist die bisherige 1-pixel-genaue Geschichte eh etwas unangebracht. Muss ich drüber nachdenken.
Wenn du jetzt [...] meinst, dann hab ich es wohl verstanden
Richtig, den Mockup meine ich.
Die besondere Darstellung war mir bislang gar nicht aufgefallen.
Ich hatte den Dialog auf unterschiedlichen Hintergründen ausprobiert (vor allem auch über dem komplexen "Files"-Tab in "Home"). Man kann bei einem Dialog nicht immer steuern, über was er dargestellt wird und daher hatte ich mir überlegt, ein trennendes Element einzuführen. In 99% der Fälle wäre es wahrscheinlich gar nicht nötig, aber manchmal wäre es doch ganz schön. Ich würde auf den Spezialfall erstmal keine sehr große Energie verschwenden, so zentral ist das nicht.
Sind im Grunde aber ja nur 8 PETSCII-ähnliche Zeichen, die drum-rum gemalt werden müssen.
Richtig. Nur ist das wahrscheinlich nicht die schnellste Routine. ich denke, wenn man diese "Chars" gleich zusammen mit dem Kasten zeichnen könnte (mit Sonderbehandlung für Randbereiche), könnte es schneller sein. Aber da kann man sich wahrscheinlich als Programmierer richtig austoben, was das Optimieren der Zeichen-Routinen angeht.
Es sollte halt anders laufen als bei GEOS, wo man zugucken kann, wie bei Dialogen erst der Schatten als ganze Fläche gezeichnet wird, dann (1 Char versetzt) die Dialog-Fläche und dann noch der 1px-Rand (und die Inhalte). Und beim Restore des Hintergrunds wird erst die Fläche das Schattens rückgebaut und dann nochmal die Dialog-Fläche (die ja nur noch aus etwas Rand besteht) auf die gleiche Weise. Genau sowas möchte ich ja beschleunigen und wenn die Darstellung meines Dialogs dem im Wege steht, dann muss ich mir halt notfalls was anderes einfallen lassen.
Ich habe hier mal die kleine Herausforderung bei der verdeckenden Darstellung von Dialogen aufgezeigt:
Hier sieht man, was passieren kann, wenn der App-Entwickler nicht aufpasst: Der blaue Kopf des Dialogs verschmilzt mit der blauen Spaltenbenennung. Sowas passiert wahrscheinlich selten (weil ich entsprechende Vorgaben machen würde) aber es könnte passieren.
1) Ganz einfache Lösung: Dialog eine Zeile tiefer positionieren. (Da im Hintergrund keine frei verschiebbaren Fenster liegen, sondern alles seinen Platz hat, kann man gut erkennen, ob irgendwo Farben ungünstig aneinander stoßen.)
2) Alternative: Man legt einen 1 Char breiten Rahmen um den Dialog. Hier mit Schatten, der zwar "nichts kostet", da er einfach über eine andere Background-Color entsteht – aber nicht so gut zum restlichen 3D-freien Flat-Design passt.
3) Das gleiche Prinzip, nur mit einer umlaufend anderen Background-Color.
4) Und hier die Lösung, für die ich mich erst einmal entschieden habe. Die Background-Color des Randes wird auf die "Dokumenten"-Farbe (hellgrau) des darunter liegenden Layers (hier Home-Screen) gesetzt. Dadurch stoßen optisch keine Hintergrund-Elemente an den Dialog und es trennt ihn gut ab vom Rest, ist aber nicht so auffällig wie die beiden vorhergehenden Lösungen. Aber wie gesagt: Sollte es wegen des zusätzlichen Randes Performance-Problem geben, würde ich einfach auf Lösung 1 setzen. Erfordert halt "Brain 2.0" des jeweiligen App-Entwicklers.
(der aufmerksame Betrachter kann ein neu hinzugekommenes Widget erkennen)
Also eins muss man dir lassen.
Das schaut echt so extremst charmant aus.
Löst wirklich einen "Habenwollen"-Reflex bei mir aus.
Sieht echt spitze aus!
Super, dass Hexworx sich das zumutet 
.
Schade, dass nicht doch irgendwie eine Kooperation mit Arndt möglich zu sein scheint (er ist ja auch schon ziemlich weit in das Zeichensatz- OS eingedrungen), da dieser ja die richtigen Kenntnisse für einen OS- Unterbau zu haben scheinnt und somit der perfekte Partner für Hexworx wäre
Danke euch beiden.
Ich habe mir die Sache mit den Dialogen nochmal durch den Kopf gehen lassen und tendiere jetzt doch eher dazu, Lösung 1 zu favorisieren. Sollen sich die App-Entwickler (sollte es welche geben) doch etwas Gedanken machen und aufpassen, dass Dialoge gut erkennbar platziert werden – ist ja keine Raketenwissenschaft. Von der Optik und auch von der technischen Umsetzung her her ist es die klarste Lösung. Keine halb eingefärbten Chars, sondern schöne, simple Kästen.
3) Das gleiche Prinzip, nur mit einer umlaufend anderen Background-Color.
4) Und hier die Lösung, für die ich mich erst einmal entschieden habe. Die Background-Color des Randes wird auf die "Dokumenten"-Farbe (hellgrau) des darunter liegenden Layers (hier Home-Screen) gesetzt.
Wobei man das ja auch dem User überlassen kann. Wenn er einen violetten Rand möchte, darf er sich das ja gern so einstellen.
der aufmerksame Betrachter kann ein neu hinzugekommenes Widget erkennen
Ganz wichtig 
!
Super, dass Hexworx sich das zumutet .
Erstmal sehen, wie weit ich komme. Noch macht es zumindest Spaß dran weiter zu machen.
Schade, dass nicht doch irgendwie eine Kooperation mit Arndt möglich zu sein scheint (er ist ja auch schon ziemlich weit in das Zeichensatz- OS eingedrungen), da dieser ja die richtigen Kenntnisse für einen OS- Unterbau zu haben scheinnt und somit der perfekte Partner für Hexworx wäre
Etwas geglotzt habe ich ja schon bei Arndt (Header). Es wird sicherlich auch möglich sein, einige (Disk-)Routinen von ihm zu 'entleihen' (mit freundlicher Erwähnung natürlich). Wo und wie viel Sinn das Macht, weiß ich aber noch nicht. Vielleicht ist es teils sogar doch einfacher, es gleich selbst neu zu machen.
Am coden bin ich im Moment quasi gar nicht, sondern nur am Planen/Rumdenken, wie das Grundgerüst werden soll/muss. Da gehen noch ein paar Monde ins Land.
tendiere jetzt doch eher dazu, Lösung 1 zu favorisieren
Es macht sicherlich auch einen Unterschied, ob man nur den statischen 'Screenshot' betrachtet, oder das Fenster aufploppt. Da weiß man dann schon, wo die Ränder vom Fenster sind.
Ich werde auf jeden Fall beide Varianten ausprobieren. Wenn der Rand keine spürbare Zeit kostet, dann vielleicht doch besser mit.
Ganz wichtig !
Ich zeige gerne das eine oder andere Widget, um die Fantasie der Betrachter anzuregen. Die in der Home-App permanent sichtbaren Widgets ermöglichen ja Lösungen, die bisher nicht denkbar waren bzw. sonst ein externes Display voraussetzen. Für Modder ist es sicherlich nicht uninteressant, Infos aus dem Inneren des Rechners zu bekommen, z.B. die Temperatur. Ich finde, dass das Konzept ganz neue Möglichkeiten bietet.
Einzelne Widgets könnten sich zusätzlich als Bildschirmschoner anmelden und die Infos auch auf dem ansonsten schwarzen Display anzeigen.
Am coden bin ich im Moment quasi gar nicht, sondern nur am Planen/Rumdenken, wie das Grundgerüst werden soll/muss.
Das ist auch wichtig. Vielleicht kannst du dir als Inspirationsquelle Dokumentationen von anderen GUIs/Systemen angucken, wie GEOS, GEM, GOS usw. Die haben damals sicherlich nicht alles falsch gemacht und da sind bestimmt gute Konzepte dabei. Man muss ja das Rad nicht neu erfinden, wenn es schon ein paar Räder gibt.
Es macht sicherlich auch einen Unterschied, ob man nur den statischen 'Screenshot' betrachtet, oder das Fenster aufploppt. Da weiß man dann schon, wo die Ränder vom Fenster sind.
Auf jeden Fall. Deswegen mache ich mir da auch nicht allzu große Sorgen. Ich versuche nur, mögliche Sonderfälle möglichst früh zu kommunizieren – später ist es oft schwierig, sowas noch einzubauen.
(der aufmerksame Betrachter kann ein neu hinzugekommenes Widget erkennen)
Temp und Lüfterdrehzahl, woher nimmt der C64/128 diese Werte? 
Wobei man das ja auch dem User überlassen kann. Wenn er einen violetten Rand möchte, darf er sich das ja gern so einstellen.
Bin da auch eher der Meinung der User kann/darf sich das selber einstellen, solang es natürlich programmtechnisch machbar ist.
Sonst kann ich nur sagen: 
Gruss C=Mac.
Temp und Lüfterdrehzahl, woher nimmt der C64/128 diese Werte?
Keine Fantasie? Wer es wirklich wissen will, wird Sensoren einbauen und irgendwie intern an den Userport hängen. Und mit einem kleinen, selbst programmierten, Widget sieht er dann, während er am Rechner sitzt, permanent die Werte. Das ist doch das, was ich zeigen möchte: es gäbe viele neue Möglichkeiten.
Es wird sicherlich auch möglich sein, einige (Disk-)Routinen von ihm zu 'entleihen'
Kein Problem!
Arndt
Kein Problem!
Danke!
Perfekt angeordnet und eingerichteter Arbeitsplatz!
Ordnung und ein gepflegtes Äußeres während der Arbeit muss schon sein . Werd mich jetzt aber mal aus dem Anzug pellen. Feierabend .
Da Hexworx wahrscheinlich mit seinen GUI-Planungen zu tun hat und sich die anderen technisch versierten leider etwas rar machen, plaudere ich einfach mal weiter und erzähle von ein paar angedachten Details:
Ich hatte ja mal die geplante Hi-DPI-Darstellung des C128 erwähnt. Hier ist ein Mockup, der das illustrieren soll. Wie gesagt, da durch die 640 Pixel in der Breite gegenüber den 320 Pixeln des C64 die Fläche nicht wirklich größer wird (der Bildschirm bleibt gleich groß), macht es Sinn, nicht die Fläche zu erweitern (und damit die Darstellung zu verzerren), sondern die Feinheit zu erhöhen. Um Speicherplatz zu sparen, würde ich darauf verzichten, alle Elemente in einer feineren Version vorzuhalten, sondern nur die Fonts an die erhöhte Auflösung anzupassen. So erhöht man mit relativ wenig Aufwand die Darstellungsqualität (und Lesbarkeit) beim C128.
Allerdings müsste man dafür das Font-Format etwas anpassen, da die normalen C64-Fonts dafür nicht mehr ausreichen (mehr als 8 Pixel in der Breite). Die Werte der Buchstaben-Breiten-Tabellen (die in den ersten 16 Zeichen des Fonts stecken könnten) würde man einfach verdoppeln, sodass die Umbrüche identisch zur C64-Version wären.
Sieht ja alles sehr toll aus. Aber passt das ALLES auch in den Speicher eines C64, oder wird das wieder ne Nachladeorgie?
Aber passt das ALLES auch in den Speicher eines C64, oder wird das wieder ne Nachladeorgie?
Das passt entweder in den Speicher oder aber es lädt so schnell von Modul/RAM-Disk/SD-Card nach, dass du es nicht merkst. (Das ist zumindest der Plan.)
Das hängt natürlich auch ein wenig davon ab, was du mit "alles" meinst. Der OS-Kern (sofern nicht wieder jemand behauptet, es gäbe keinen), das GUI und die freigehaltenen Buffer sollten soviel RAM-Speicher frei lassen, dass darin jeweils eine größere App Platz findet. Das wäre beim Start halt die Home-App, die wiederum aus App-Screen, Datei-Verwaltung, System-Verwaltung und Widget-Bereich besteht. Ob diese App monolithisch angelegt ist oder aber (neben den Widgets) Module nachlädt/ersetzt, muss sich erst noch zeigen. Aber wenn sie Teile nachladen sollte, dann aus einem externen ROM- oder RAM-Bereich, wodurch man keine Wartezeiten spüren würde.
Andere Apps, die die Home-App im Speicher ersetzen würden, wie z.B. ein Texteditor, Disk-Kopierer oder Grafikprogramm, müssten natürlich geladen werden. Allerdings gäbe es auch hier die Möglichkeit, das aus einem ROM- oder RAM-Modul zu tun, was blitzschnell gehen würde. Muss man auf weitere Massenspeicher zurückgreifen, hängt die Performance natürlich von dem jeweiligen Laufwerk ab. SD2IEC in Kombination mit JiffyDOS (oder anderen Schnelllade-Routinen) wäre z.B. relativ fix.
Da die Programmier-kundigen hier ja keine Lust haben, mal ein Konzept vorzulegen, wie man z.B. den Speicher unter Verwendung des EasyFlashs aufteilen könnte, habe ich angefangen, mich in das Thema einzulesen. Macht mir zwar keinen Spaß und für andere wäre es wahrscheinlich ein Klacks aber was soll's. Demnächst gibt es also eine Memory-Map von mir, die zeigt, wie ich mir das vorstellen könnte. Auch das wäre natürlich nur eine Diskussions-Grundlage.
