letzter Beitrag von steril am
Habe das gleiche Problem mit der 1581. Habe unter Vice alle Laufwerksadressen einmal durch getestet, aber er zeigt im Explorer nichts an ( Habe natürlich jeweils die passende Laufwerksemulation eingeschaltet). Mit 1541 ging es ohne Probleme.
Wenn ich heute Abend noch Zeit finde teste ich es mal an original Hardware.
Ich würde das generell nur azf realer Hardware testen.
Mal wieder ein Zwischenstand. Ich hab mich ein bisschen mit einem regelrechten Explorer beschäftigt und vorläufig ist jetzt das dabei rausgekommen:
Ist vom FileCopy inspiriert, aber zeigt nur ein Directory. In diesem Directory werden Files, die goDos was sagen, mit einem kleinen Icon (hier "M" für MOD, es gibt noch 8 andere) gekennzeichnet. Das lässt einen schnell unterscheiden zwischen goDos- und normalen Programmen. Klickt man eine Datei an, kommt rechts das FileInfo dazu und Dateien, die zu goDos gehören, lassen sich dann installieren, also ins System einbinden (noch nicht fertig). Würde man ein normales C64-Programm anklicken, käme nur ein kurzes FileInfo und der Knopf "Launch" statt "Inst" würde hervorgehoben. Bei reinen Datenfiles gar keiner. Klickt man auf den hervorgehobenen Button, verlässt man damit goDos und startet das ausgewählte Prog (auch noch nicht fertig). ChDir und ChPart sollen die jeweiligen Module holen und ausführen (Directory wechseln bzw. Partitionen wechseln, die Module gibt es schon, aber die Funktion ist auch noch nicht fertig). Oben unter "U&I" werden noch zwei oder drei Knöpfe eingebaut für "Delete", "Rename" und (vielleicht) "New". Das Fragezeichen fragt den Floppy-Fehlerkanal ab, mit den Pfeilen scrollt man.
Mal sehen, wie es weitergeht.
Arndt
Klickt man eine Datei an, kommt rechts das FileInfo dazu
D.h. du hältst reichlich Bildschirmplatz frei für eine Funktion, die im alltäglichen Betrieb kaum gebraucht wird und verbannst dafür elementare Funktionen eines Dateimanagers wie Delete, Rename, Copy... in ein gut verstecktes Menü?
Es würde m.E. mehr Sinn machen, die direkt zugänglichen Informationen über eine Datei im eigentlichen Lister anzuzeigen (Blocks, Dateiname, P/S/U/D für den Dateityp) und daneben wieder eine senkrechte Liste mit allen Funktionen des Dateimanagers, inklusive einem Knopf für "FileInfo".
Für "Launch", "Install" o.ä. braucht es m.E. keinen Knopf, in jeder GUI starte/öffne ich Dateien per Maus(doppel-)klick. Im Zweifelsfall (will der User starten oder installieren?) wird kurz per Requester nachgefragt.
Eine Datei, deren Namen mit "MOD." beginnt, nochmals separat zu kennzeichnen, braucht es m.E. nicht. Ich sehe das "MOD." lange bevor ich das "m" wahrnehme.
und Dateien, die zu goDos gehören, lassen sich dann installieren, also ins System einbinden (noch nicht fertig).
Was bedeutet "installieren"?
ChDir und ChPart sollen die jeweiligen Module holen und ausführen
Auch für "Verzeichnis öffnen" sollte es keinen Knopf geben, das erledigt man überall anders auch per Anklicken des Verzeichnisses. Verzeichnisse erkennen muss goDos ja sowieso (du willst sie ja schließlich im Verzeichnisinhalt als solche kennzeichnen, oder nicht?), dann kann man auch auf "Verzeichnis angeklickt" entsprechend reagieren. Was es braucht, sind Knöpfe für "Parent" und eventuell "Root".
Oben unter "U&I" werden noch zwei oder drei Knöpfe eingebaut für "Delete", "Rename" und (vielleicht) "New".
Dinge, die m.E. in einem U&I-"Knopf" (ich plädiere immer noch für Aktivierung per rechter Maustaste statt einem Knopf) gut aufgehoben wären:
Das sind schon mal fünf Punkte, die m.E. *immer* drin sein müssten - dabei würde ich es belassen, anstatt auch noch Programmfunktionen dort unterzubringen.
Hallo Arndt,
Ich muss deinen Entwurf auch leider reklamieren. Dateiinfos würde ich nur auf Wunsch/Abruf anzeigen lassen.
Der Dateimanager sollte unbedingt zwei Fenster haben, um auch Dateioperationen einfach zu handhaben. Wie
ich mir das in etwa vorstelle, hab ich Dir in den Entwurf gemalt.
Zur Erklärung:
Soweit im Groben.
die direkt zugänglichen Informationen über eine Datei im eigentlichen Lister anzuzeigen
So wie bei FIBR? Also ein Fenster über die ganze Breite... hm. Ja... Und die FileInfos kann man in einem Fenster anzeigen, wenn man es ausdrücklich will. Gefällt mir auch besser.
starte/öffne ich Dateien per Maus(doppel-)klick
Ja, klar. Kommt ja noch. Ist eben *vorläufig* 
Ich sehe das "MOD." lange bevor ich das "m" wahrnehme
Du siehst aber jetzt schnell alle Dateien, die NICHT zu goDos gehören. Darauf kam es mir an.
Was bedeutet "installieren"?
In goDos einbinden.
Auch für "Verzeichnis öffnen" sollte es keinen Knopf geben, das erledigt man überall anders auch per Anklicken des Verzeichnisses.
Ja - wie gesagt - kommt noch. Ich baue ja noch am Gerüst.
für Aktivierung per rechter Maustaste
Das wird schwierig, denn die rechte Maustaste wird in Port 1 nicht abgefragt.
wie bei Windows über ein "X" in der rechten Ecke
Stimmt. In GoDot ist das die linke obere Ecke (hin und wieder).
Wechseln von Partitionen erfolgt im Fateifenster mittels übergeordneten Verzeichnis "...".
Hat Korodny ja auch schon vorgeschlagen.
Ok. Dann wieder ran.
Arndt
Kleine Bemerkung: Es sind typischerweise zwei .. Punkte, nicht 3 unter Windows fuer den Wechsel ins hoehere Verzeichnis. Ich wuerde das Rad hier nicht neu erfinden.
Das Anzeigen von Infos auf Wunsch waere besser, aber dann so, wie Arndt es schon gezeigt hat, *fix* zuschaltbar, damit man mit dem Cursor schnell Dateien so durchstoebern und "analysieren" kann, ohne den Info jedes Mal einschalten zu muessen.
IIRC hatte das Norton Commander damals auch so.
Der Dateimanager sollte unbedingt zwei Fenster haben, um auch Dateioperationen einfach zu handhaben.
Das Problem dabei ist, dass die (IMHO wesentlichen) Infos:
Zusammen mit zwei Trennzeichen dazwischen und zwei Zeichen für den Rahmen drum herum bereits 24 Zeichen belegen. Zwei vollständige Einträge passen also gar nicht nebeneinander auf den Schirm. D.h.: Entweder fängst du an zu kürzen - in deinem Beispiel fehlen Dateigröße und -Typ, außerdem werden nur 13 (?) Zeichen vom Dateinamen angezeigt - oder du zeigst nur ein Verzeichnis an.
Die einzige Operationen, die zwei Verzeichnisse benötigt, ist Copy/Move - wenn die Funktion aufgerufen wird, kann man den Nutzer auch schnell per Dialogfenster nach dem gewünschten Zielverzeichnis/-Laufwerk fragen. Eventuell könnte man die Problematik nochmal etwas verkleinern in dem man irgendwie Karteikartenreiter simuliert - so dass der Nutzer in verschiedenen Verzeichnissen stöbern kann, auch wenn immer nur eines davon angezeigt wird.
In deinem Beispiel gibt es das gleiche Usability-Problem wie bei Arndt - woran erkenne ich ein Verzeichnis? Ist "Doom" eine ausführbare Datei oder ein Verzeichnis?
Das "Verlassen" Symbol würde ich, ähnlich wie bei Windows über ein "X" in der rechten Ecke machen. Ein Extrabutton finde ich unnötig.
Das "X" ist auch ein Button 
Ein Menü, wie von Arndt vorgeschlagen, hätte den Vorteil, dass man mehrere generell benötigte Funktionen (Prefs, Quit, About...) odrt unterbringen könnte. Wenn man das konsequent in allen Anwendungen umsetzt ist es ergonomisch und spart Bildschirmplatz.
Ja, klar. Kommt ja noch. Ist eben *vorläufig*
Ach so, sorry - war mir nicht klar dass sich solche grundlegenden Sachen noch ändern.
Du siehst aber jetzt schnell alle Dateien, die NICHT zu goDos gehören. Darauf kam es mir an.
Aber wie relevant ist das in der Praxis? Ich habe ein Verzeichnis/ein Laufwerk wo ich alle goDos-Dateien hinkopiere - schon Godot hatte ja ein "Systemlaufwerk". Im normalen Betrieb sind in diesem Verzeichnisses bzw. auf diesem Laufwerk *alle* Dateien goDos-Dateien, während ich auf anderen Laufwerken bzw. in anderen Verzeichnissen so gut wie nie goDos-Dateien begegne.
Wichtiger wäre mir (in jedem Dateirequester) die Anzeige des Dateityps: ich muss zwischen "DIR", "PRG/SEQ/USR" oder "DEL" unterscheiden können.
In goDos einbinden.
Das hilft mir auch nicht weiter Unter "installieren" hätte ich mir vorgestellt "ins goDos-Verzeichnis kopieren". Wenn goDos immer auf dem aktuellen Lauwerk und dem Systemlaufwerk nach Systemdateien sucht, und diese Systemdateien entsprechenden Namenskonventionen folgen (MOD.*, APP.* usw.), was muss ich dann noch "einbinden"?
Das wird schwierig, denn die rechte Maustaste wird in Port 1 nicht abgefragt.
Autsch, wusste ich gar nicht. Dann würde ich ehrlich gesagt die Maus auf Port 2 verlegen.
Mein Gedanke bei "rechter Knopf=Menü" war einfach, das der rechte Knopf einer Maus heutzutage als (Kontext-) Menü-Knopf etabliert ist, dass man das Menü immer mit der gleichen Methode aufrufen kann - unabhängig davon, was gerade angezeigt wird (man denke an einen Bildanzeiger/eine Diashow für Hires-Bilder) und dass dem Programmierer weniger Grenzen bei der Bildschirm-Gestaltung gesetzt werden: Wenn "U&I" ein Knopf ist, muss er aus ergonomischen Gründen immer an der selben Stelle sein - der Programmierer muss sich dann überlegen, was er in den drei Bildschirmzeilen, die der U&I-Knopf (das zu tippen ist Folter!) erzwingt, noch sinnvolles unterbringt.
Hat Korodny ja auch schon vorgeschlagen.
Nee, hat er nicht Der "..." Eintrag im eigentlichen Verzeichnis-Listing ist weniger Ergonomisch als ein ausgesprochener "Parent"-Knopf, weil ich u.U. erst wieder nach oben scrollen muss um ihn zu sehen. Das wird bei goDos durch die fehlenden Scrollbalken m.E. nochmal etwas schlimmer. Deswegen würde ich einen separaten Knopf bevorzugen.
Autsch, wusste ich gar nicht. Dann würde ich ehrlich gesagt die Maus auf Port 2 verlegen.
Ich nehme an, dass Arndt sich auf seinen Maustreiber bezog und nicht auf die Hardware, denn hardwaretechnisch sind die Ports - abgesehen von der Lightpen-Leitung - komplett identisch.
Bei einer 1351 hat die rechte Maustaste den gleichen Effekt wie "Joystick nach vorn", die Abfrage ist also trivial.
Warum macht Ihr die Dateifenster nicht untereinander? Dann habt ich mehr Zeichen pro Zeile für den Inhalt, könnt zwischen den beiden Fenstern Schaltflächen für CPY, REN, DEL, MOV für Kopieren, Umbenennen, Löschen und Verschieben anlegen.
Wie kann man das ganze eigentlich testen? Ich bekomme das nichtmal kompiliert. Was zum einen daran liegt, dass im Code mit "..\" referenziert wird (statt "../", was ACME vermutlich selbst unter Windows kapieren wuerde - ich arbeite jedoch unter Linux und brauche daher "../"), aber selbst wenn ich das behebe, weiss ich ueberhaupt nicht, welches ueberhaupt die "main"-Datei ist oder was ich tun muss. Daher wundert es mich, wie hier so viele schreiben dass sie es alle schon laengst testen und rumprobieren usw... stehe ich hier auf dem Schlauch?
Warum macht Ihr die Dateifenster nicht untereinander? Dann habt ich mehr Zeichen pro Zeile für den Inhalt, könnt zwischen den beiden Fenstern Schaltflächen für CPY, REN, DEL, MOV für Kopieren, Umbenennen, Löschen und Verschieben anlegen.
Das ist doch hässlich. Jeder Dateimanager hat zwei Fenster nebeneinander.
Alles anzeigenDas Problem dabei ist, dass die (IMHO wesentlichen) Infos:
- Dateiname (16 Zeichen)
- Größe (3 Zeichen)
- Typ (1 Zeichen)
Zusammen mit zwei Trennzeichen dazwischen und zwei Zeichen für den Rahmen drum herum bereits 24 Zeichen belegen. Zwei vollständige Einträge passen also gar nicht nebeneinander auf den Schirm. D.h.: Entweder fängst du an zu kürzen - in deinem Beispiel fehlen Dateigröße und -Typ, außerdem werden nur 13 (?) Zeichen vom Dateinamen angezeigt - oder du zeigst nur ein Verzeichnis an.
Die einzige Operationen, die zwei Verzeichnisse benötigt, ist Copy/Move - wenn die Funktion aufgerufen wird, kann man den Nutzer auch schnell per Dialogfenster nach dem gewünschten Zielverzeichnis/-Laufwerk fragen. Eventuell könnte man die Problematik nochmal etwas verkleinern in dem man irgendwie Karteikartenreiter simuliert - so dass der Nutzer in verschiedenen Verzeichnissen stöbern kann, auch wenn immer nur eines davon angezeigt wird.
In deinem Beispiel gibt es das gleiche Usability-Problem wie bei Arndt - woran erkenne ich ein Verzeichnis? Ist "Doom" eine ausführbare Datei oder ein Verzeichnis?
Ja das sollte ja nicht so das Problem darstellen. Zur Not macht Arndt das wie beim Godot Copy Modul (Bild) oder 64Net Copy.
Das ist doch hässlich. Jeder Dateimanager hat zwei Fenster nebeneinander.
quark, form follows funktion. ich hab auch schon mal unter Vista mit 2x3 Fenstern Dateien sortiert....
Die Frage ist eher, ob "sehschlitze" mit 5 bis 7 Dateinanem überhaupt nützlich sind.....
sl FXXS
also vielleicht hätte ich da eine idee
statt 40x25 80x25
Das ist auf dem C64 aber nur über einen Trick möglich, und dazu benötigt man den Bitmap-Modus. Hier soll es ja aber um ein OS im Zeichenmodus gehen.
Zwar auch trickreich, aber ohne Bitmap-Modus: 80 Zeichen/Zeile im Interlace-Modus!
Den Dateityp könnte man doch auch einfach über eine Einfärbung des Namens anzeigen. Grün=Verzeichnis, Rot = PRG etc...
Den Dateityp könnte man doch auch einfach über eine Einfärbung des Namens anzeigen. Grün=Verzeichnis, Rot = PRG etc...
BASH lässt grüßen 
...
