ASCII Text Editoren

Es gibt 167 Antworten in diesem Thema, welches 5.268 mal aufgerufen wurde. Der letzte Beitrag (18. Oktober 2025 um 18:28) ist von Jammet.

  • Ich frage mich halt, ob ich nicht alles Nötige in den 3 Zeilen lösen könnte. Bis auf den Dateidialog, bei dem ich vielleicht auf die fertige Fullscreen-Lösung von Petrus zurückgreifen würde.

    DOS ist m.E. kein guter Vergleich, weil dort doppelt so viel Text auf den Schirm passt. 1000 Zeichen sind schon verdammt wenig, jedes weitere Zeichen schmerzt da in meinen Augen.

    Die ständig sichtbare(n) Menüzeile(n) könnte(n) auch in Rahmen-Sprites abgelegt werden. Dann nehmen die keinen wertvollen Platz für den Text weg.

  • Und mit 3 Zeilen bin ich auf dem C64 fast noch sparsam. Guck dir mal die beliebten (wohl meistgenutzten) C64-Textverarbeitungen StarTexter Und Vizawrite an:

    Genau mit denen habe ich jahrelang gearbeitet - da stammt meine Abneigung gegen zu viele UI-Zeilen ja her ;) *Heutige* Abneigung muss man korrekterweise sagen, damals kannte man ja nichts besseres.

    Aber so arbeitet doch niemand: Erst Commodore-taste drücken, lesen und dann die zweite Taste.

    Macintosh-Umsteiger, die sich keine Shortcuts merken können, könnten dann so arbeiten. Der Rest von uns macht einfach weiter Control-F ohne hinzugucken, um den nötigen Punkt aufzurufen.

    Da würde nichts "eingeblendet" werden.

    Noch mal, zum Mitschreiben: Ich widerspreche dir nicht. Wenn du es nicht "Einblenden" nennen willst, nenne es "Überschreiben" oder "Magic Bar". Mein Punkt ist lediglich, das ein nur bei Bedarf sichtbares Menü keinen Mehraufwand macht.

    Ich nicht so oft. Aber vielleicht jemand, der dort lebt und sich für mein ß kein bisschen interessiert. Du scheinst davon auszugehen, dass nur Deutsche, Schweizer und Franzosen den Editor (mit gleichem Encoding) verwenden. Mich erinnert das an die Lokalisierungen z.B. des C128, der auch immer nur die nötigsten Zeichen der jeweiligen Sprachversion enthielt.

    Nein, das hast du völlig falsch verstanden. Bei Nutzung von UTF-8/Unicode ist jedem Zeichen im Text ein fester, "weltweit" einzigartiger Code zugeordnet. Die Einschränkung ist lediglich, ob wir das jeweilige Zeichen auch korrekt darstellen können/wollen. Jemand der keine Umlaute braucht, oder kyrillische Zeichen, hat dann eben einen anderen Ausschnitt aus dem Unicode-Spektrum als darstellbar konfiguriert.

    Bei Nutzung einer 8-Bit Codepage wie ISO, tritt dagegen u.U. genau das von dir beschriebene Problem auf: Ein und derselbe Zeichencode bedeutet vielleicht bei mir etwas völlig anderes als bei einem Slawen, Türken oder Russen. Und Windows schert sich sowieso einen Dreck um ISO-8859, das geht von CP-1252 aus, da darfst du schon mal jedes verwendete Euro-Zeichen nachbessern.

  • Vielleicht könnte man ja mal bei TD1334 anfragen? Sein Bitte melde dich an, um diesen Link zu sehen. ist noch keinen Monat alt, der Code deshalb noch weitestgehend frisch im Kopf und vielleicht hat er Ideen, wie man den auch für "ASCII-kompatibel" anpassen kann?

    Oh danke, der ist komplett an mir vorbei gegangen. PA-Basic ist mir auch neu, lauter aufregende Sachen ;) Der Editor ist gerade nach drei Zeilen Text abgeschmiert, muss ich mir mal noch genauer ansehen.

  • Ich würde gerne darauf verzichten, erst das Menü einblenden zu müssen. Wenn ich es immer sehe, muss ich mir nicht merken, mit welchem Shortcut ich die jeweiligen Punkte aktivieren kann. Ich muss mir aber noch genauer angucken, wie die alten DOS-Textverarbeitungen genau damit umgegangen sind.

    Alle DOS Nutzer welche das original Microsoft Edit benutzt haben, sahen die oberste Ebene permanent eingeblendet. Bei dein allermeisten anderen DOS Programmen war das ebenso der Fall, auch Programmen welche keine Text Editoren waren.

    Qedit habe ich vorher schonmal erwähnt, das war ein Programm welches das nicht getan hat. Dort drückt man auf ESC, und dann erscheint die oberste Ebene erst. Aber nur als Auswahlzeile, man benutzt hier die Cursortesten um eine Kategorie zu wählen. Diese öffnet man mit Curserdown, und sie gehorcht weiterhin den Cursortasten um beliebig zwischen Kategorien zu springen, merkt sich aber pro Kategorie auch die letzte Position der dortigen Auswahl. Das geht ganz gut, ich habe Jahre damit gearbeitet.

    Der direkte Sprung in eine Kategorie hinein mittels z.B. Strg+E ist gleichzeitig auch möglich.

    Prinzipiell ist für mein Empfinden die permanente Einblendung der Top-Ebene Benutzerfreundlich, auch wenn sie eine Zeile für sich beansprucht.

    Sind eigentlich (vielleicht optionale wenigstens) 80 Zeichen etwas, was du dir nicht wünschst? Gerade bei vielen DOS Texten, wo oft auch mit 8xLeertaste als Ident/Tab rudimentär formatiert wurde, tut das sehr viel für die Lesbarkeit. Ich würde mir das schon sehnlich wünschen, aber ich bin eben nur eine Stimme. Ich finde es sehr spannend dass ihr das überhaupt erwägt und besprecht, eventuell sogar etwas gemacht wird. Das habe ich so noch nie erlebt. Bin dankbar.

    Aber so arbeitet doch niemand: Erst Commodore-taste drücken, lesen und dann die zweite Taste.

    Macintosh-Umsteiger, die sich keine Shortcuts merken können, könnten dann so arbeiten. Der Rest von uns macht einfach weiter Control-F ohne hinzugucken, um den nötigen Punkt aufzurufen.


    Wenn es die Umstände der Umsetzung erlauben ist (für mich) eine Hervorhebung der Aktionstaste ständig oder bei Aufruf der Menüs schon sehr wichtig für den Komfort des Benutzers. Ja, Commodore oder CONTROL+F (Ich tendiere hier stark zur Commodore Taste, weil sie Positional *deutlich* näher an Ctrl am PC wäre) benutzen wir alle Nase lang, aber es gibt auch eventuell exotischeres, und durch das wiederholte drücken der Metataste um die Aktionstastenkürzel "blinken" zu lassen verschafft vielen am Anfang die Klarheit und beschleunigt das erlernen der Kürzel. Wobei da auch nicht unbedingt erst etwas versteckt sein, und danach wieder zu sehen sein muss, hauptsache wäre meiner Meinung nach, sie würden überhaupt irgendwie hervorgehoben.

  • Wenn du es nicht "Einblenden" nennen willst, nenne es "Überschreiben" oder "Magic Bar".

    Nein, es gibt bei dem ursprünglichen Konzept auch kein Überschreiben, kein Überlappen, kein Einblenden, kein Puffern oder was auch immer. Das wären zwei "(HTML-) Frames", die nichts miteinander zu tun hätten. Vielleicht nochmal so: "Darunter" ist schwarz, kein Text. ;)

    Macintosh-Umsteiger, die sich keine Shortcuts merken können

    Dazu sage ich mal nichts.

    Nein, das hast du völlig falsch verstanden.

    Ich habe dich schon ganz richtig verstanden und ich weiß, was Unicode ist (das sollte jedem hier mitlesenden klar sein, auch dir). Ich sprach von der Lokalisierung deines Editors. Der kann je nach persönlich ausgewählten Zeichenvorrat eben nur diese (128) darstellen (auch wenn er die anderen dank "Rettung" nicht entsorgt). Der gute Mann aus Ålesund sieht halt bei deinem Konzept mein ß nicht und ich sein Å auch nicht, sondern jeweils Platzhalter (aber beide Zeichen blieben erhalten, solange deine Rettungs-Tabelle nicht vollläuft).

    Und Windows schert sich sowieso einen Dreck um ISO-8859

    Selbst Windows sollte intern längst auf Unicode umgestellt sein, Code Page 1252 dürfte längst Geschichte sein (auch wenn MS gerne "eigene Standards" forciert). Und was die Editoren kennen, sollte davon unabhängig sein – meiner kennt dutzende von Encodings (einen Ausschnitt hatte ich gezeigt) und mein Browser auch. So kam ich ja erst auf die Idee, eines von denen auf dem C64 zu implementieren.

    Du scheinst mich misszuverstehen: Ich bin durchaus von deiner angedachten Konverter-Lösung vorsichtig angetan (sollte sie reibungslos funktionieren) und frage deshalb nach. Man bekommt sie eben nicht "kostenlos" und muss dafür auf anderes verzichten (und hat Arbeit) und ich frage mich halt, ob sich der Aufwand rechnet. Aber grundsätzlich finde ich, wie ich auch schon sagte, die Idee, auf UTF-8 zu setzen, gut. In erster Linie, weil die Lösung DAU-freundlich wäre und sich User keine Gedanken darüber machen müssten, wie sie einen Text auf dem PC abspeichern müssen, damit er auf dem C64 verlustfrei verarbeitet werden kann (die meisten haben den Begriff Encoding noch nie gehört). Wenig Arbeit für den User bedeutet aber meistens mehr Arbeit für den Programmierer.

    Wenn du den Konverter schon fertig in der Schublade hast (wie dein GUI), würde ich den gerne mal ALeX zeigen. Man muss das Rad ja nicht mehrfach neu erfinden.

    Sind eigentlich (vielleicht optionale wenigstens) 80 Zeichen etwas, was du dir nicht wünschst?

    Doch, schon. Aber das ist noch eine ganz andere Baustelle. Dann kommt (auf dem C64) Bitmap-Darstellung ins Spiel (und dann wäre Korodny wohl ohnehin raus). Aber man hätte noch ganz andere Möglichkeiten, weil man dann definitiv auf inverse Zeichen verzichten (256 Zeichen statt 128) und Schrift-Stile darstellen könnte und noch so einiges mehr. Aber halt auch: 8/9 KB RAM Mehrverbraucher durch die Darstellung usw. Da wäre dann die Nutzung einer Speichererweiterung wohl unerlässlich.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Das möchte ich einem Programmierer nicht im ersten Schritt als mögliches Projekt vorschlagen.

    Bitte melde dich an, um diesen Link zu sehen. | Meine Lieblings-Themen im Forum64:

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • Wenn es die Umstände der Umsetzung erlauben ist (für mich) eine Hervorhebung der Aktionstaste ständig oder bei Aufruf der Menüs schon sehr wichtig für den Komfort des Benutzers.

    Ich arbeite unter Linux oft ziemlich Tastatur-zentriert - weil ich die Hände wegen Textbearbeitung sowieso an der Tastatur habe oder es komfortabler finde als beispielsweise das Touchpad meines Laptops.

    Ich würde im Leben nicht "Alt-D" (für "Datei"-Menü) drücken, um dann mit den Cursortasten und Enter auf "Öffnen" zu gehen - oder "f" zu drücken, den Shortcut für "Öffnen". Ich benutze natürlich direkt Control-O, Control-S und Control-Shift-S für "Öffnen", "Speichern" und "Speichern unter". Diese Menü-Navigation - bzw. Nichtnavigation - halte ich für erheblich praxisfreundlicher als die umständliche Cursortasten-Variante. Und wenn man sich an etablierten Shortcuts orientiert, sollte sich auch die Lernkurve in Grenzen halten: jeder von euch weiß, was Control-X/C/V macht.

    Mit einem Menü in einer Zeile fällt die Möglichkeit weg, Control-O und ähnliches direkt im Menü anzuzeigen und den Nutzer so ganz nebenbei über diese Möglichkeit zu informieren. Darüber hinaus noch Shorctuts für "Datei" gefolgt von "Öffnen" penetrant anzuzeigen und hervorzuheben, erzieht den Nutzer zur Nutzung dieser Steuerung, selbst wenn man den besseren (und auf modernen Systemen quasi standardisierten) Ansatz ebenfalls anbietet.

  • Der gute Mann aus Ålesund sieht halt bei deinem Konzept mein ß nicht und ich sein Å auch nicht.

    Korrekt. Aber wenn er sie sehen wollte, könnte er das so konfigurieren - das ist der Punkt. Es ist möglich ordentlich lokalisierte Ausgaben zu erstellen, ohne Kompatibilitätsverlust.

    Würdest du dagegen ISO-8859 verwenden, siehst du alle meine schönen Gedankenstriche, Anführungszeichen und Auslassungspunkte niemals - oder der Tscheche kriegt irgendwo deutsche Umlaute angezeigt, wo eigentlich was anderes stehen sollte.

    Selbst Windows sollte intern längst auf Unicode umgestellt sein, Code Page 1252 dürfte längst Geschichte sein (auch wenn MS gerne "eigene Standards" forciert).

    Es ging mir um Texte, die auf dem C64 erstellt und auf Windows geöffnet werden.

    Wenn du den Konverter schon fertig in der Schublade hast (wie dein GUI), würde ich den gerne mal ALeX zeigen. Man muss das Rad ja nicht mehrfach neu erfinden.

    Oh nein, sicher nicht. Außer ein bisschen Recherche und Notizen machen ist da noch nicht viel passiert. Sorry, wenn der Eindruck entstanden sein sollte, das war nicht gewollt.

  • Da wäre dann die Nutzung einer Speichererweiterung wohl unerlässlich.

    Ich tue mich immer noch schwer, mir einen Usecase für so einen Speicherbedarf in einem C64-Texteditor vorzustellen.

    Es wurde ja weiter oben schon erwähnt, dass man mit so 30 KB freiem Speicher problemlos gut gefüllte 10 DIN A4-Seiten Text eintippen kann (übliche Texte eher so 12 DIN A4-Seiten lang).

    Tippt denn wirklich jemand solche "Textorgien" am C64 und will dazu noch unbedingt alles in einem(!) Dokument haben, das permanent im Speicher liegen muss? Wenn es denn ein Roman sein soll, dann nimmt man halt für jedes Kapitel eine eigene Datei, dann bringt man so auch dicke Wälzer auf Disketten. ;)

  • Und wenn man sich an etablierten Shortcuts orientiert, sollte sich auch die Lernkurve in Grenzen halten: jeder von euch weiß, was Control-X/C/V macht.

    Ja, und cmd-A/O/S/Q/P/Z/I/N/W/,/F und noch ein paar andere habe ich mir auch gemerkt. Aber ich glaube nicht, dass man mit einer Hand voll Shortcuts das ganze Programm bedienen können wird. Ich finde, wie Jammet, dass es auch eine visuelle Lösung geben sollte.

    Es ging mir um Texte, die auf dem C64 erstellt und auf Windows geöffnet werden.

    Ja und, kann der Windows Editor keine anderen Encodings als CP-1252?

    Es wurde ja weiter oben schon erwähnt, dass man mit so 30 KB freiem Speicher problemlos gut gefüllte 10 DIN A4-Seiten Text eintippen kann (übliche Texte eher so 12 DIN A4-Seiten lang).

    Meine Aussage war bezogen auf einen Editor mit Bitmap-Ausgabe. Da fehlen zusätzlich 8/9 KB RAM, was rund 4 Seiten weniger bedeuten könnte. Eigentlich stelle ich mir so einen Editor eingebettet in ein Bitmap-basiertes GUI-OS vor und das sollte mE mit einer Speichererweiterung umgehen können (und damit natürlich dann auch der Editor).

    Bitte melde dich an, um diesen Link zu sehen. | Meine Lieblings-Themen im Forum64:

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • Ich arbeite unter Linux oft ziemlich Tastatur-zentriert - weil ich die Hände wegen Textbearbeitung sowieso an der Tastatur habe oder es komfortabler finde als beispielsweise das Touchpad meines Laptops.

    Ich würde im Leben nicht "Alt-D" (für "Datei"-Menü) drücken, um dann mit den Cursortasten und Enter auf "Öffnen" zu gehen - oder "f" zu drücken, den Shortcut für "Öffnen". [...]

    Ich doch auch. Vielleicht hab ich mich etwas ungerade ausgedrückt -- ich mag beides. Ein Nachteil von dem Menüsystem im Vergleich zu *ganz* direkten Kürzeln ergibt sich erst, wenn das Menü sich auf mehrere Ebenen verschachtelt, und ganz direkte Kürzel verwenden wir auch in diesem Beispiel nicht (damit meine ich, dass alles theoretisch komplett ohne irgendein Menü geht, aber dafür so ziemlich jede Taste eine Control+ funktion hat, wirklich jede einzelne Funktion, und man mit Control+H einen Hilfebildschirm bekommt, wie das in vielen Editoren auch gerne germacht wird.

    Bei den manchen DOS Tools ihrer Zeit war beides möglich. Es gab ausreichend Tasten, und wurde wahlweise ann das Menü aufrufen und mit den Cursorn navigiert als wäre das ein Fernseher, oder alternativ direkt die erweiterten Tastenkombinationen gedrückt, die nicht mit den Menüeinträgen verbunden waren.

    In der Regel wäre das dann auch für mich meistens nicht Alt-D und Richtungtasten/Cursor, sondern ebenso wie Du es machst, also Alt-D,o.

    Sowas meinte ich eigentlich, auch wenn ich das nicht so gut ausgedrückt habe.

    Ich tue mich immer noch schwer, mir einen Usecase für so einen Speicherbedarf in einem C64-Texteditor vorzustellen.

    Mir fällt da ein berühmtes Bill Gates Zitat ein. ;3

    Dann nehm ich das erste, einfachste Beispiel was mir gerade eingefallen ist:

    Alle Verzeichnisse und Unterverzeichnisse mit allen Dateinamensendungen, die auf D64 enden, gepiped in eine Textdatei, zu durchsuchen mit Commodore+F auf dem C64.

    Logfiles aller Art. Endlos-Drucker-Dateiumleitungen. Textsammlungen aus den Unterschiedlichsten Quellen, Geschichten oder ausführliche Dokumentation, allesamt Texte wo niemand sich Gedanken darüber macht, dass bei irgendeinem Computer deswegen der Speicher zu voll würde, und deswegen die Sektionen 1-10 als 10 Dateien speichert, anstelle der einen. Es gibt immer Anwendungsfälle, es betrifft nur nicht jeden.

  • Ja, und cmd-A/O/S/Q/P/Z/I/N/W/,/F und noch ein paar andere habe ich mir auch gemerkt. Aber ich glaube nicht, dass man mit einer Hand voll Shortcuts das ganze Programm bedienen können wird. Ich finde, wie Jammet, dass es auch eine visuelle Lösung geben sollte.

    Ich stimme insofern zu, dass gutes Interface-Design bedeutet, keine Optionen vor dem Nutzer zu verstecken - oder sich an etablierte Standards zu halten. Aber...

    In deinem letzten Mockup ist entweder "Control-S" für das "Search"-Menü belegt - kann also nicht als direkter Shortcut für "Speichern" verwendet werden - oder es gibt eine Methode, das "Search"-Menü zu öffnen, die ich erst mal ausknobeln bzw. nachlesen muss. Also "Commodore-S" für "Search"? Schon bin ich am herumprobieren. Dafür opferst du zwei Bildschirmzeilen, während dein Mockup keine Infos zu freiem Textspeicher oder aktueller Position (Zeilennummer) im Text enthält.

    ich will nicht schon wieder das "Einblenden"-Fass aufmachen, aber Dinge vor dem Text einzublenden kostet dich genau gar nichts - eine Routine um Text ab Position X/Y neu zu zeichnen hat ein Texteditor ja sowieso. Also Dialog anzeigen, danach Text neu zeichnen - einen Puffer braucht es da nicht.

    Hier mal mein Vorschlag, wie so ein Menü aussehen könnte:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Bitte melde dich an, um diesen Anhang zu sehen.

    1. Niemand muss etwas raten, weil alles deutlich kommuniziert wird.
    2. Ich emuliere moderne Systeme: Anzeige der Shortcuts hinter dem Menüpunkt - da weiß jeder "Aha, nächstes Mal kann ich einfach "Control-O" drücken"
    3. Ich spare mir u.U. eine Hilfeseite, weil jeder Shortcut ja im Menü zu finden ist

    Ja und, kann der Windows Editor keine anderen Encodings als CP-1252?

    CP-1252 kann man u.U. als "nicht-ISO" identifizieren (wenn Zeichen benutzt werden, die bei ISO für Control Codes reserviert sind). Umgekehrt geht das allerdings nicht. Ein Windows-Editor wird deswegen - vermute ich - wegen der CP-1252-Dominanz auf Windows immer von CP-1252 ausgehen. Es sei denn, der Nutzer teilt ihm etwas anderes mit und der Editor beherrscht es - Notepad kann bspw. UTF-8, aber kein ISO.

  • Ich finde diesem Ansatz das Menü zu gestalten auch absolut funktionell. Absolut in Ordnung. :3 Einziger Kritikpunkt wäre der visuelle "Genuss", insofern man bei einem Text Editor von sowas reden kann, versuche ich mir das gerade mit der Font, Farbwahl und dem Designeinfluss von Retrofan vorzustellen und die Ästethik wäre auch da.

    ^^ Hoffe hier über Menüästhetik zu schreiben verstößt gegen keine geltenden Regeln ;3 Ich sehe das wie Doc Browne in Back to the Future. Wenn man schon eine Zeitmaschine erfindet ... haha.

  • Einziger Kritikpunkt wäre der visuelle "Genuss"

    Um Himmels willen, ich habe sicher nicht den Anspruch mit Retrofan in Sachen Ästhetik zu konkurrieren. Die Screenshots sollen lediglich das Prinzip verdeutlichen.

    (oh, und danke)

  • Alle Verzeichnisse und Unterverzeichnisse mit allen Dateinamensendungen, die auf D64 enden, gepiped in eine Textdatei, zu durchsuchen mit Commodore+F auf dem C64.

    So eine Textdatei habe ich tatsächlich hier auf der Platte. Sie ist aktuell 79 MB groß. :D

    Zitat

    Es gibt immer Anwendungsfälle, es betrifft nur nicht jeden.

    Ich meinte, auf dem C64 halbwegs realistische Anwendungsfälle. ;)

  • Hier mal mein Vorschlag, wie so ein Menü aussehen könnte:

    Und jetzt die gleiche Struktur (und hässliche Farbkombinationen, damit keiner aufs Design achtet), nur in einer Anordnung, die nicht automatisch an CP/M-Menüs aus den 70ern (oder Billo-TV-Geräte) denken lässt. ;)

    Ich sehe da keinen Nachteil. Auf die eine Textzeile weniger sei geschxxxx. ;)

    Bitte melde dich an, um diesen Anhang zu sehen. Bitte melde dich an, um diesen Anhang zu sehen.

    Bitte melde dich an, um diesen Link zu sehen. | Meine Lieblings-Themen im Forum64:

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • Und jetzt die gleiche Struktur (und hässliche Farbkombinationen, damit keiner aufs Design achtet

    Hehe, danke.

    Ich sehe da keinen Nachteil.

    Womit öffne ich das "Search"-Menü? Das ist nicht ersichtlich.

    Du verschenkst eine Bildschirmzeile, um dem Nutzer ggfs. statt <STOP>, <F>, <S> ein <Commodore-F>, <S> zu ermöglichen. Mir wäre die Bildschirmzeile wichtiger, da die meisten Nutzer in der Praxis nach kurzer Einarbeitungszeit in 90% der Fälle sowieso die Direktkürzel verwenden werden. Aber diesen Vorteil deines Ansatzes kann ich ja sowieso nachbilden, wenn die oberste Menü-Ebene auch Shortcuts bekommt:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Jetzt führt <Commodore-F>, <S> genauso zum Ziel.

    Um den "STOP=MENU" Eintrag in der Statuszeile los zu werden - weil er hässlich ist, oder man den Platz anderweitig nutzen will - könnte man auch einfach bei leerem Textspeicher - also so lange der Nutzer noch keinen Text eingegeben oder eine Datei geladen hat - einen Hinweistext an zentraler Stelle einblenden:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Ist halt Geschmaksache. Ich glaube nicht, dass wir uns da noch einig werden ;)

  • Vergesst gleich mal meinen PAB-Edit Ansatz. Das war ein Just for Fun Project um mit meinem PABasic zu experimentieren. Das Programm ist jetzt schon am Anschlag was Speicherverbrauch und Geschwindigkeit angeht, denn es ist immer noch interpretiertes Basic ;-)


    Ich habe mir nicht alles durchgelesen, nur den Teil ab dem ich erwähnt wurde.

    Soll der Texteditor ein PRG werden oder kann das auch ein Modul sein?

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.

  • Von TD1334:

    Zitat

    Ich habe mir nicht alles durchgelesen, nur den Teil ab dem ich erwähnt wurde.
    Soll der Texteditor ein PRG werden oder kann das auch ein Modul sein?

    Momentan zitiert man immer gleich einen so langen Bart mit, da mach ich das lieber von Hand.

    Ist PAB-Edit wirklich ein ASCII Editor? Das wäre wirklich wichtig. Ich persönlich würde den im PRG Format von Datenträgern aller Art aufrufen.



    Muss gestehen, die Tastaturkürzel sind nicht so meins, wirkt archaisch wenn man sich anschaut wie z.B. Retrofan und Korodny das in Mockups so zeigen. Das ist natürlich subjektiv. Da empfand ich tatsächlich vi als zugänglich im Vergleich. Und vi ist in den Augen vieler Leute unbenutzbar, weil sie nicht wissen, wie man zwischen Operationsmodus und Eingabmodus wechselt, oder das Ding beendet, oder was speichert... dabei ist vi sehr logisch und benutzt z.B. alternative Cursorfunktionen an die man sich schnell gewöhnt. Generell bin ich aber ein Freund positionaler Layouts. Also als Beispiel -- in vi sind HJKL die Cursortasten wenn man nicht im Editormodus ist. Daran bin ich mindestens genauso gewöhnt wie Gamer an ihr WASD. Mit einer Meta Taste zusammen könnten sie jederzeit zum markieren benützt werden.

    Oder anderes Beispiel.

    Vorher:

    (Shift+) Commdore +N nächste Seite (Markierung Starten)
    (Shift+) Commdore +V vorherige Seite (Markierung Beenden)

    positional:

    (Shift+) Commodore +N links/vorherige Seite (erweitere Markierung ein Zeichen nach links)
    (Shift+) Commodore +M vorherige Seite (erweitere Markierung ein Zeichen weiter nach rechts)

    Sind nur so meine Gedanken dazu bisher. Finde es aber grandios, dass du Scheiss und Zeit in so etwas hinsteckst, denn ich habe in diesem Thread ja schon festgestellt: etwas modernere Tools oder bestimmte Arten von Tools sind nicht gerade wie Sand am Strand...