letzter Beitrag von steril am
quark, form follows funktion. ich hab auch schon mal unter Vista mit 2x3 Fenstern Dateien sortiert....
Das sind immer noch mehr als ein Fenster, richtig.
ZitatDie Frage ist eher, ob "sehschlitze" mit 5 bis 7 Dateinanem überhaupt nützlich sind.....
sl FXXS
Davon kann nicht die Rede sein, da ja mehr als 7 Einträge die Liste anzeigt. Einfach mal das originale Copy von Godot anschauen.
Dateiinfos würde ich nur auf Wunsch/Abruf anzeigen lassen
Ja, mache ich nun auch so. Die letzten Versionen waren Versionen, in denen ich Verschiedenes ausprobiert habe (eben die FileInfo-Sache, aber auch eine Darstellung mit nur einem Dir-Fenster, ein paar Anzeige-Tricks in GoDot, hat mich weitergebracht!) Bin jetzt wieder zurück auf der Commander-Darstellung von FileCopy.
Der Dateimanager sollte unbedingt zwei Fenster haben
Finde ich auch. Der interne Aufwand dafür ist eh gering.
Die einzige Operationen, die zwei Verzeichnisse benötigt, ist Copy/Move
Was man aber wahrscheinlich am häufigsten tun wird...
Ach so, sorry - war mir nicht klar dass sich solche grundlegenden Sachen noch ändern.
Hehe... 
Sprichst du mit deinen Team-Kollegen auch so? 
Bei einer 1351 hat die rechte Maustaste den gleichen Effekt wie "Joystick nach vorn", die Abfrage ist also trivial
Das war damals eine Entscheidung. Mehrere Voraussetzungen spielen da hinein: 1. Wir wollten alle uns bekannten Eingabeinstrumente gleichzeitig bedienen können. Daher muss man entscheiden, welchen Port man wofür festlegt. Wenn ich mich richtig erinnere, liegen GEOS-Mäuse auf Port 1. Wir wollten nicht ein lästiges Umstöpseln provozieren. 2. In meiner Erinnerung klingelt da irgendwie, dass die rechte Maustaste auf den Joystick in Port 2 gemappt ist (nicht Port 1). Da liegt aber nun unser Joystick-Treiber. Wenn der nach vorne bewegt würde, sich würde also die rechte Maustaste angesprochen fühlen. 3. Da auch die Tastatur als Maussteuerung bedienbar sein sollte (und ist), sind wir so vorgegangen, dass wir Joystickbewegungen in Tastendrücke ummappen. Da hat die rechte Maustaste keinen Platz mehr. Welcher dumme Hardware-Entwickler legt auch eine Mausfunktion auf die Abfrage eines konkurrierenden Eingabeinstruments?
welches ueberhaupt die "main"-Datei ist oder was ich tun muss
Wirft dich das schon aus der Bahn? Das kann ich mir nicht vorstellen. Sei mal ein bisschen geduldiger...
Ich danke Korodny für seine kritischen, aber immer konstruktiven Hinweise. Sie bringen mich jedes Mal wieder darauf zurück, dass ich bei goDos über das GoDot-System hinausdenken muss. Ganz wichtig, Mann!
Arndt
Naja bei ueber 100 Dateien und einem komplizierten Konzept mit "Slots" und was auch immer... hab ich nun wirklich keinen Plan, wie man das jetzt korrekt kompiliert. Und eine Readme mit 3 Saetzen und einem acme-Kommando waere doch sicherlich nicht zu viel verlangt, oder nicht?
Davon kann nicht die Rede sein, da ja mehr als 7 Einträge die Liste anzeigt. Einfach mal das originale Copy von Godot anschauen.
ich sprach davon, das von den ursprünglichen Einträge untereinander sind nur fünf bis sieben davon übrig bleiben, wenn man zwei breite Fenster unteinander anordnet...
Somit wohl doch das nebeneinander mit weniger informationen praktischer wäre.
In meiner Erinnerung klingelt da irgendwie, dass die rechte Maustaste auf den Joystick in Port 2 gemappt ist (nicht Port 1). [...] Welcher dumme Hardware-Entwickler legt auch eine Mausfunktion auf die Abfrage eines konkurrierenden Eingabeinstruments?
Äh, watt? Wie soll denn ein an Port 1 angeschlossenes Gerät die Leitungen von Port 2 beeinflussen? Natürlich kann man eine Maus in Port 1 (inklusive rechter Maustaste) und einen Joystick in Port 2 gleichzeitig abfragen, genau das macht z.B. das "DuoDriver"-Beispielprogramm im "examples"-Verzeichnis von ACME.
Bei der Screenshot-Flut dachte ich, ich mach auch mal einen Mockup 
Mein Ansatz ist einfach der, dass das Teil ja als alltäglicher Dateimanager einsetzbar sein soll - das könnte ich mir ohne die Anzeige von Dateityp und -größe einfach für mich selbst nicht vorstellen. Zwei Verzeichnisse untereinander endet m.E. dagegen mit den genannten "Sehschlitzen": Vier Zeichen für Rahmen, (mindestens) vier für die Anzeige der beiden aktiven Laufwerke bzw. Verzeichnisse - das wird schnell eng.
Wie wären zwei Verzeichnissen nebeneinander, die alle notwendigen Infos enthalten, von denen (aus Platzgründen) aber immer nur eines vollständig sichtbar ist? Das zweite, halb verdeckte Verzeichnis würde dann hoffentlich noch genug Infos bieten, um zu erkennen wo ich bin, was dort an Dateien herumliegt etc.
Ich habe im Mockup getrickst - Scrollbalken gibt es ja nicht. Dann wäre ein Verzeichnisfester im Zweifelsfall zwei Zeichen schmäler, dafür müsste die Anzeige unterhalb des Verzeichnisses eben durch rauf/runter-Knöpfe ersetzt werden. Bin außerdem bestimmt kein Designer, das Ding soll nur das Prinzip verdeutlichen:
Oberhalb der Verzeichnisses werden Partition ("P:") und Laufwerksnummer/-Typ angezeigt Ein Klick darauf zum Wechsel. Unterhalb des Verzeichnisses werden aktueller Pfad bzw. bei Laufwerken ohne Verzeichnisse die freien Blocks und evtl. der Header angezeigt.
Das aktive (d.h. vollständige) Fenster ist bei Copy/Move die Quelle, das andere Fenster ist das Ziel. Klick ins inaktive Fenster bringt dieses nach vorn.
(Edit: Mockup nachgebessert)
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.
Ja schon gut, Du olle Mimose
ich sprach davon, das von den ursprünglichen Einträge untereinander sind nur fünf bis sieben davon übrig bleiben, wenn man zwei breite Fenster unteinander anordnet...
Somit wohl doch das nebeneinander mit weniger informationen praktischer wäre.
Ja, Anhand deines Screen verstehe ich nun was Du genau meintest. Wäre auch eine Variante.
Ich habe im Mockup getrickst - Scrollbalken gibt es ja nicht.
Warum eigentlich nicht ? Geht das technisch nicht ?
Hehe...
Das sollte kein Seitenhieb sein? Hatte das tatsächlich schlicht falsch verstanden.
In meiner Erinnerung klingelt da irgendwie, dass die rechte Maustaste auf den Joystick in Port 2 gemappt ist (nicht Port 1).
Das wird zumindest im Handbuch so nicht erwähnt: "The left mouse button is mapped to what would be the fire button on a joystick. The right mouse button is mapped to what would be that UP direction on a joystick." - wenn das der andere Port wäre, hätten sie das wohl dazu geschrieben?
Mir fällt zusätzlich zu MacBacon's Hinweis mindestens noch der GEOS-Klon Supra64 ein, der hatte Maus (inklusive rechtem Knopf) und Joystick auch gleichzeitig aktiv.
Ich danke Korodny für seine kritischen, aber immer konstruktiven Hinweise.
Wow, äh - danke. Im Übrigen herzlichen Dank sowohl für Godot (auch wenn ich das damals lediglich als einfaches Konvertierprogramm benutzt habe und goDos.
Warum eigentlich nicht ? Geht das technisch nicht ?
Ich versuche lediglich, die Anzahl der Dings die Arndt bis heute Abend für uns erledigt haben soll auf ein Minimum zu begrenzen - wegen Scrollbalken nerven wir ihn dann morgen
Technisch sollten Scrollbalken kein großes Problem sein, ist halt wieder eine Platzfrage.
Wo soll das bitte hin, oder bzw. von wo aus soll das ganze gestartet werden, wen es fertig ist ?
Von einem Modul aus?
Von einer Ultimate 1541II (nachfolger), und TC64?
Oder noch allgemeiner gefragt, generell von einer REU aus?
Oder wie hat sich das der entwickler, und die Gemeinde das gedacht?
Brotscheibe
der hatte Maus (inklusive rechtem Knopf) und Joystick auch gleichzeitig aktiv
Ich hatte in meiner Erinnerung gewühlt. War wohl lückenhaft. Jedenfalls hatten wir uns entschieden, die rechte Maustaste nicht immer mit einem nach oben verschwindenden Mauszeiger zu koppeln... Der Mac geht ja schließlich auch mit einer Taste (war unsere Beschwichtigung damals).
Technisch sollten Scrollbalken kein großes Problem sein
Na ja, wenn sie nicht gleiten müssen, dann müsste ich mal was austüfteln. Senkrechte variable Objekte gab es bisher in GoDot noch nicht. Aber unmöglich ist es (natürlich) nicht.
Wo soll das bitte hin, oder bzw. von wo aus soll das ganze gestartet werden, wen es fertig ist ?
Klick. Da.
Das ist der Plan. Wie? Ist noch die Frage.
Und hier noch die Konkretisierung von Korodnys Mockup (noch ohne Dir-Anzeige und mit gefaketen Beschriftungen, aber ansonsten bereits klickbar.
Werde mal daran weiter überlegen. Da fehlt mir der Statusbalken, der auch die Fortschrittsanzeige macht, und eine Drive-Auswahl müsste auch per Fenster gehen, oder?
Arndt
Ich bin gespannt was daraus wird. Und wie genau das umgestzt wird. Und von welcher Quelle es nun dan geladen wird.
Viel Glück bei dein Projekt.
Brotscheibe
Hab mir das noch mal überlegt: Theoretisch reicht es (mir zumindest ), wenn man zwischen DIR, DEL und "Sonstigem" (PRG, SEQ, USR) unterscheiden kann. Dann könnte man sich die Spalte für den Programmtyp auch sparen - DIR und DEL haben ja keine Größe, also notiert man dort statt der Größe einfach DIR oder DEL. Ohne Scrollbalken wäre man dann inklusive Rahmen bei 22 Zeichen, mit Scrollbalken bei 23 oder 24 - d.h. vom "überlagerten" Verzeichnis wären selbst im schlimmsten Fall nur die Dateigröße verdeckt, die Dateinamen sind weiter fast komplett sichtbar.
Hab mein Mockup noch mal entsprechend angepasst:
Finde die Dateinamen im rechten Lister sind da immer noch perfekt zu erraten.
Na ja, wenn sie nicht gleiten müssen, dann müsste ich mal was austüfteln. Senkrechte variable Objekte gab es bisher in GoDot noch nicht. Aber unmöglich ist es (natürlich) nicht.
Gleiten müssen sie sicher nicht. Ein Scrollbalken wäre halt ziemlicher Komfortgewinn.
Und hier noch die Konkretisierung von Korodnys Mockup (noch ohne Dir-Anzeige und mit gefaketen Beschriftungen, aber ansonsten bereits klickbar.
Wow, macht doch was her
ZitatWerde mal daran weiter überlegen. Da fehlt mir der Statusbalken, der auch die Fortschrittsanzeige macht, und eine Drive-Auswahl müsste auch per Fenster gehen, oder?
Zur Drive Auswahl klickt man in meinem Mockup auf die "Titelleiste" eines Verzeichnisses, die das aktuelle Laufwerk anzeigt - dann geht ein entsprechender Requester auf. Was meinst du mit "müsste auch per Fenster gehen"?
Statusbalken habe ich bewusst weg gelassen. Da die GUI ja sowieso komplett blockiert ist, würde ich für die Fortschrittsanzeige ein Dialogfenster mit Fortschrittsbalken aufmachen. Das macht auch optisch gleich klar, dass der Großteil des Bildschirms gerade nicht anklickbar ist. Und auf Fehler würde ich Anwender sowieso auch immer per Dialogfenster hinweisen. "00, Ok, 00" brauche ich dagegen nicht als Rückmeldung, bekomme ich auf anderen Systemen ja auch nicht.
Meine Meinung?
Fehlende Informationen oder überlappende Fenster bei denen man Namen erraten muss? Ich glaube, ich fände "Sehschlitze" besser. So schmal wären die auch gar nicht. Das Menü müsste kpl. nach rechts verlagert werden und die Ansicht umschaltbar zwischen einem und zwei Fenster (ein "Split" Knopf). Jedes Anzeigefenster bekommt eine Titelzeile (mit LW-ID, LW-Typ und Partition, Pfad oder "Blocks free") die fest ist und nicht scrollt. Mit einem Klick auf die Titelzeile kommt man zur LW-Auswahl (am besten die Auswahl der ID gleich mit angezeigtem Typ wie 1541, 1581, SD2IEC, ...). Wenn die Titelleiste invers ist oder zumindest eine andere Farbe hat, brauch man noch nicht einmal eine Trennung zwischen Titelleiste und Dateianzeige. Wieviel Platz wäre im Splitscreen-Modus? 2 Titelleisten, 2 obere und 2 untere Rahmen - der Rest sollte für die Dateilisten zur Verfügung stehen. Den Splitscreen brauch man halt "nur" für Copy und Move. Das macht man wohl häufiger als Delete und Rename aber der Explorer soll ja auch zum starten von Programmen genutzt werden und das wird wohl mit Abstand die häufigste Aufgabe sein. Dafür reicht der Singlescreen vollkommen (98% der Fälle?).
Welche Buttons brauch man? Starten eines Programms und Wechsel in ein Verzeichnis bzw. Image-Datei sollte über einen Doppelklick gehen. Dann wären da:
- Home (Sprung ins Root-Verzeichnis wenn in einem Unterverzeichnis oder in einem Disk-Image / ansonsten Sprung an den Anfang der Dateiliste)
- Up (Eine Verzeichnisebene höher wenn in Unterverzeichnis bzw. verlassen eines Disk-Images / ansonsten Sprung an den Anfang der Dateiliste)
- Split (Wechsel zwischen Singlescreen und Splitscreen und zurück)
- Del (Löschen von Dateien oder Verzeichnissen)
- Ren (Umbenennen einer Datei oder eines Verzeichnisses)
- Copy (Kopieren vom aktivem Fenster zu inaktivem Fenster bzw. Zielauswahl bei Singlescreen)
- Move (Verschieben von aktivem Fenster zu inaktivem Fenster oder Zielauswahl bei Singlescreen)
- New (Erstellen eines neuen Unterverzeichnisses, einer Disk-Image-Datei, ...)
- Format (Formatieren des aktuellen Laufwerks bzw. des aktuell geöffneten Disk-Image)
- Info (Anzeigen des Fehlerkanals)
- CMD (Senden eines Befehls an das aktuelle Laufwerk)
Hab ich noch etwas vergessen?
Leider habe ich zur Zeit keine Möglichkeit ein Mockup zu malen aber vielleicht war es auch so verständlich genug, wie ich mir das so vorstellen könnte. Was haltet ihr davon?
Finde die Dateinamen im rechten Lister sind da immer noch perfekt zu erraten.
Meine Meinung dazu:
Ein Dateitool, bei dem ich Dateinamen "erraten" muss, hat seinen Sinn verfehlt.
Bei 40 Zeichen in der Breite macht es für Dateinamen keinen Sinn, auch nur irgendwie zwei Fenster nebeneinander anzeigen zu lassen. Es werden immer Informationen verdeckt bzw. ausgeblendet werden. Da ist ja dann LOAD"$",8 noch übersichtlicher.
Über zwei Fenster bei Dateinamendarstellung nebeneinander braucht man sinnvollerweise erst nachdenken, wenn man die Schrift entsprechend proportional verkleinert darstellt. Mit festen 40 Zeichen kann man sich das schenken.
Ich mag den NC Style, sehe hier auch das Problem mit den 40 Zeichen. Die beiden Fenster untereinander anzuordnen halte ich für den besseren Weg.
Beim IDE64 klappt das auch gut.
Gruß
Chris
Ich hab noch einen Diskcopy vergessen. Erste Idee war, dass man das als einzelne App realisieren könnte. Aber es ist ja nicht immer nur von IDx nach IDy kopieren. Es kann ja häufiger vorkommen, dass man eine Disk in ein Image oder umgekehrt kopiert. Da man sich bei der Image-Auswahl möglicherweise durch Verzeichnisse hangeln muss, ist das meiner Meinung nach gut im Explorer aufgehoben. Dazu noch eine Idee: Wenn man versucht ein Diskcopy z.B. von einer 1541 zu einem SD2IEC (ohne gemountetes Image) zu machen, sollte automatisch im aktuellen Verzeichnis des SD2IEC ein D64-Image erstellt werden und der Inhalt dann da rein kopiert werden. Image-Name gleich Diskettenname?
Man könnte es ja so machen: Datei(en) auswählen und dann ein klick auf "Copy" macht Dateicopy. Klick auf Titelleiste bei einer Floppy oder bei einem gemounteten Image und dann auf "Copy" macht ein Diskcopy. Und Doppelklick auf Titelleiste führt zu Laufwerksauswahl.
Ein Diskcopy z.B. von einer 1541 zu einer 1581 sollte ein Dateicopy aller Dateien erzeugen.
Ich hab etwas besseres als ein Mockup gefunden! Da könnte/sollte man sich dran orientieren:
http://www.mobilefx.de/html/dracopy.html
Es ist eins meiner Lieblings Tools. Es ist vielleicht nicht die stylischste Oberfläche aber extrem übersichtlich und super funktionell. Ich finde, dass der Sascha hier eine top Lösung geschaffen hat.
Ich hab etwas besseres als ein Mockup gefunden! Da könnte/sollte man sich dran orientieren:
http://www.mobilefx.de/html/dracopy.html
Es ist eins meiner Lieblings Tools. Es ist vielleicht nicht die stylischste Oberfläche aber extrem übersichtlich und super funktionell. Ich finde, dass der Sascha hier eine top Lösung geschaffen hat.
Naja, sieht aber nicht so schön aus.
Ich hab noch einen Diskcopy vergessen.
Gute Idee wobei ich aber denke, dass wir Arndt jetzt nicht überlasten sollten. Ich finde das sowieso schon hammer, dass er sich hinstellt und das "mal so eben" für uns macht.
- Info (Anzeigen des Fehlerkanals)
Bei markierter Titelleiste: LW-ID, LW-Typ, Datenträgername, Fehlerkanal, ...
Bei markierter Datei: Dateiinfo (so wie bei dem Zwischenstand auf der rechten Seite)
Naja, sieht aber nicht so schön aus.
Ich sage ja, dass das nicht so stylisch ist aber Funktionalität ist mir speziell an dieser Stelle deutlich wichtiger. Überlappende Fenster oder Infos wie Dateigröße oder Dateityp nicht sichtbar fände ich deutlich schlechter.
Gute Idee wobei ich aber denke, dass wir Arndt jetzt nicht überlasten sollten.
Hat ja alles Zeit. Man kann es ja Träumerei nennen oder definieren eines Endziels?!
Ich finde das sowieso schon hammer, dass er sich hinstellt und das "mal so eben" für uns macht.
Das steht außer Frage!
