Hello, Guest the thread was called1.8k times and contains 49 replays

last post from Retrofan at the

Kein File-Requester in C64-Anwendungen

  • GoDots Filerequester braucht rund 500 Bytes Code

    Na dann hab ich ja gut geschätzt. ^^

    der Filenamenspeicher ist der Bildschirmspeicher selber (die Anzeige)

    Was - wie in der Lösung von LogicDeLuxe - ein Nachladen beim Blättern nötig macht und bei einer DIskette mit hauptsächlich Bildern als Datei wegen der geringen Dateianzahl nicht so sehr auffällt, sich bei Verzeichnissen mit sehr vielen Einträgen jedoch unangenehm bemerkbar macht. Hierbei ist der Hinweis von LogicDeLuxe auch zu beachten, daß die Begrenzung der 1541 auf 144 Einträge bei größeren Datenträgern nicht einmal vorhanden ist und das komplette Laden eines Verzeichnisses noch schwieriger macht. Dennoch ist dieses dann notwendig, wenn man z. B. Dateinamen alphabetisch sortieren möchte (, wie es moderne Requester vormachen). Meine bisherige Lösung sieht daher auch so aus, einen großen Batzen an temporären Speicher zu alloziieren, in dem die Verzeichnisdaten aufgenommen werden können. Das setzt allerdings voraus, daß die eigentliche Applikation diesen Speicher für sich ebenso temporär nutzen kann (z. B. als Kopie der Bitmap für ein Undo).

    So oder so sieht man aber bereits bei GoDot oder LogicDeLuxe, daß ein Dateirequester einen nicht zu unterschätzenden zusätzlichen Aufwand bedeutet, mit dem sich ein Programmierer nicht gerne auseinandersetzen will.

  • Das fehlen von der Anzeige des Dateikatalogs in vielen Anwendungen, welche mich einfach nach irgendwelchen Dateinamen fragen, irritierte mich auch oft schon als Kind; nicht erst seit ich die alten Anwendungen wiederentdeckt habe. Das war so ein verdammt flottes Diskettenlaufwerk, das DDI-1 an meinem CPC 464, da mal den Katalog einzuladen hätte kaum Zeit gebraucht. Filerequester sah ich auch in CPC Anwendungen nie. Ich kann mich an kein einziges Programm mit so einen "Feature" erinnern, und habe es mir so oft gewünscht.


    Mich würde mal interessieren wie eine "positiv Beispiel" Liste auf dem C64 aussehen würde. Ich bin ziemlich sicher, in JASWORD kann man Verzeichnisinhalte anzeigen lassen, z.B. Gut so.

  • Mich würde mal interessieren wie eine "positiv Beispiel" Liste auf dem C64 aussehen würde.


    Ein simpler Dialog ist im sd2iec Kernal eingebaut. Das Verzeichnis im linken Bereich scrollt, Statusleiste oben und Menü rechts sind fix.


  • Da der Amiga mehrfach erwähnt wurde:

    Beim Amiga mit Kick/WB 1.x sah es ja nun auch nicht so viel besser aus. Da gab es eben auch keine OS-Routinen, um einen Standard-Dateirequester aufzurufen - den gab es schlicht nicht. Somit haben alle ihr eigenes Süppchen gekocht. Und da es auch noch kein User-Interface-Style-Guide gab, sah auch alles anders aus. Und manchmal, wie im Falle von Microsoft AmigaBasic, wurde es auch einfach nur ohne Dateiauswahlrequester dahingerotzt...


    Will sagen: Was dieses Thema angeht, war das AmigaOS erst ab 2.0 (1990?) ein mehr oder weniger gutes Beispiel.

  • Mich würde mal interessieren wie eine "positiv Beispiel" Liste auf dem C64 aussehen würde.

    GEOS und Final Cartridge III fallen mir da ein. Um nur ein Programm zu starten, ist letzterer allerdings doch etwas umständlich.

    Und dann wären da natürlich noch die diversen Browser, die einzig für den Zweck gemacht sind, komfortabel zu navigieren und Dateien zu laden und auszuführen.

    Und in den 80'ern hatten wir schon einen Schnelllader, den man auf vielen Disketten an erster Stelle vor fand. Der hatte so viele PRG-Dateien angezeigt, wie auf den Bildschirm passen, und man konnte eine zum Laden auswählen. Scrollen ging allerdings nicht, aber so viele Dateien zum Ausführen hat man ja auch nicht auf einer Diskette.

    Ich bin ziemlich sicher, in JASWORD kann man Verzeichnisinhalte anzeigen lassen

    Inhaltsverzeichnis anzeigen ist zwar nicht selbstverständlich, aber doch schon in der Regel vorhanden. Für die Ausnahmen hat Dolphin DOS, wie gesagt, das Problem schon gelöst. Programme, die noch nichtmal das haben, wurden wahrscheinlich auf Datasette programmiert. Dort erwartet man einfach, daß der Anwender sich zumindest die Position der Datei notiert hat.

    Im Grunde ist aber der Thread-Titel etwas unpräzise. Eine schlichte Aufforderung, einen Dateinamen einzutippen ist streng genommen auch schon ein File-Requester. Hier geht es aber eben um Komfortlösungen, die einem das Merken und Eintippen von Dateinamen ersparen.


    Wenn ich an Eingabeaufforderungen an modernen Systemen denke, dann möchte ich die Zwischenablage auch nicht mehr missen. Die hat mir schon häufig das Merken und Eintippen von Dateien (komplett mit Pfad) erspart. Und Dolphin DOS hat damals schon eine Zwischenablage am C64 bereitgestellt.

  • Der sagenumwobene TapeComposer von 2009 hat soetwas natuerlich (indirekt):

    https://csdb.dk/release/?id=75452

    Aber auch KoalaPainter von 1983.

    https://csdb.dk/release/?id=65698

    Halt immer dann wenn man es brauchte. Das geht ja fliessend in den Klicki-Bunti-Bereich ueber.

  • Und da es auch noch kein User-Interface-Style-Guide gab, sah auch alles anders aus.

    Das Problem hat man leider heute auch noch auf praktisch allen gängigen Systemen. Daß man in der Regel mehrere APIs am Start hat, macht die Sache nicht besser. Allein GTK und Java sind fast überall vorhanden und bringen ihre eigenen Filerequester mit. Und dann gibt's auch immer wieder solche Entwickler, denen das System nicht hübsch genug ist, und das Rad lieber neu erfinden.

  • Allein GTK und Java sind fast überall vorhanden und bringen ihre eigenen Filerequester mit.

    Zu Java kann ich nichts sagen, GTK (und auch Qt) verwenden aber die Standard-Dialoge der Zielplattform, falls vorhanden (nicht auf den ganzen *nix-Systemen mit X11, da es solche da nicht gibt, da sind die von GTK und Qt quasi der Standard) -- es sei denn der Programmierer will das bewusst anders haben, z.B. um den Dialog selbst erweitern zu können (wie Vice mit der integrierten Anzeige des Disk-Inhalts). Oder "aufhübschen", was aber definitiv eine blöde Idee™ ist.


    edit: Standarddialoge verwenden heißt natürlich auch, mit deren Einschränkungen klarkommen -- das musste ich bei V1541Commander leider feststellen. Der Qt-eigene Dialog hat zum Beispiel keine Probleme mit einem Filter *.p[0-9][0-9] für "P00" (also PC64 PRG container) Files. In der Windows Version musste ich auf *.p00 ausweichen, weil der Dialog von Windows den "besseren" Filter nicht versteht. War für mich allerdings kein Grund, deshalb nicht den Standarddialog zu nehmen.


    edit2: Bogen zurück: Ich finde am Verlauf der Diskussion sieht man sehr schön, dass so ein Dialog, Requester, wie immer man es nennen mag, sinnvollerweise Aufgabe des Betriebssystems (bzw zumindest der "standard" libraries, wie das z.B. bei Linux, BSD etc mit Qt und GTK der Fall ist) sein sollte. Der C64 konnte das gar nicht leisten. Dass Anwendungsprogramme selbst etwas implementieren ist nett, aber wurde damals (wahrscheinlich zurecht) als optional angesehen.

  • In der Windows Version musste ich auf *.p00 ausweichen

    Fand ich schon immer blöd, wenn Tools sich darauf beschränken. Der PC64 war mein erster Emulator am PC. Ich habe meine ausführbaren Dateien immer gerne als .p64 gehabt, weil sie so leichter aufzufinden sind. Insbesondere bei der damaligen 8.3-Beschränkung der Dateinamen, war es nämlich nicht immer so einfach, bei Spielen mit 100 Dateien die richtige zu finden.

  • Tja, wenn die Wahl daraus besteht, auf Windows nur einen Filter für .p00 anzubieten, oder den Qt-Filedialog zu verwenden, dann wähle ich lieber ersteres -- aber es ist wirklich etwas blöd :o Zwar ist auch der Qt Filedialog auf Windows so gestylt, dass es "nach dem Original aussieht", aber so ganz exakt ist das wahrscheinlich nicht, und wenn Microsoft in nem neueren Windows was ändert, müsste Qt erst "nachziehen" -- das wollte ich nicht. Natürlich kann man auf Windows trotzdem auch ein .p64 öffnen, muss dafür aber den Filter für "Alle Dateien (*)" wählen ...


    Das ist hier allerdings ein bisschen OT, hatte das ja nur als Beispiel erwähnt, was so alles zu bedenken sein kann ;)

  • Ich meine, dass beispielsweise das Malprogramm "Advanced OCP Art Studio" und auch das Spiel "Boulder Dash Construction Kit" solche Dateiauswahl-Dialoge bieten. Und bei Spielen wie "Maniac Mansion" passte immer nur genau ein Savegame auf eine Diskette, also brauchte man dort keinen Dateinamen für das Savegame eingeben. :-)

  • Ich hatte schon länger mal überlegt, den Dateiauswahldialog den ich ich diversen Tools einsetze mal als konfigurierbare Library zur Verfügung zu stellen. Das würde es zumindest für neue Programme leichter machen, mehr Komfort zu bieten.

    Gute Idee!


    Offenbar haben die Dolphin DOS-Entwickler diesen Mangel auch bemerkt und deswegen CTRL-D mit Directory anzeigen belegt. Das funktioniert immer, wenn ein Programm die Eingabe über das KERNAL macht.

    Das ist ja cool. So kann ich mir quasi in jedem Programm ein Disk-Inhaltsverzeichnis ansehen? Aber muss dann nicht zumindest der aktuelle Bildschirm irgendwohin gerettet werden, um ihn danach zu restaurieren?


    Beim Amiga mit Kick/WB 1.x sah es ja nun auch nicht so viel besser aus. Da gab es eben auch keine OS-Routinen, um einen Standard-Dateirequester aufzurufen - den gab es schlicht nicht. Somit haben alle ihr eigenes Süppchen gekocht.

    Das ist ja interessant. Ich hatte schon an anderer Stelle gelesen, dass das Amiga-GUI anfangs recht spartanisch war, was grafische wie funktionale Assets anging.


    GEOS und Final Cartridge III fallen mir da ein.

    Aber auch KoalaPainter von 1983.

    Ich meine, dass beispielsweise das Malprogramm "Advanced OCP Art Studio" [...] solche Dateiauswahl-Dialoge bieten.

    Es ist interessant, dass vor allem grafische Programme (Bitmap-Darstellung) über Datei-Auswahl-Dialoge verfügten, obwohl so ein Dialog ja mit Grafik selbst nur wenig zu tun hat.


    Auch bei den Betriebssystemen hatten erst die mit GUI (also allen voran der Macintosh) File-Requester und auch andere, nicht direkt mit Grafik assoziierte Funktionen, wie Cut/Copy/Paste oder beispielsweise auch programmübergreifende Druckertreiber im Angebot. Woher kam das wohl? Im Prinzip hätten doch auch textbasierte Betriebssysteme, wie MS-DOS oder CP/M solche Funktionen bieten können.


    Liegt es (nur) daran, dass diese ganzen Konzepte im Prinzip aus der gleichen Quelle stammen und deshalb auch alle gleichzeitig mit dem GUI über die Menschheit kamen?

  • Das ist ja cool. So kann ich mir quasi in jedem Programm ein Disk-Inhaltsverzeichnis ansehen? Aber muss dann nicht zumindest der aktuelle Bildschirm irgendwohin gerettet werden, um ihn danach zu restaurieren?

    Stimmt schon, daß es einem ein sorgfältig angeordnetes Design zerschießen kann, aber das kann man auch, wenn man sonst irgendwelche Steuerungen statt Text eingibt, oder die Fehlermeldungen beim fehlgeschlagenem Ladeversuch tun das. Normalerweise wird in so einer Software nach dem Laden der Bildschirm deswegen auch generell neu aufgebaut.

  • Normalerweise wird in so einer Software nach dem Laden der Bildschirm deswegen auch generell neu aufgebaut.

    Ja, aber so wie ich das verstanden habe, weiß das Wirts-Programm ja nicht, dass Dolphin-DOS ein Directory über den Screen gelegt hat – keiner der Protagonisten kann/wird also einen Refresh auslösen, oder?

  • Auch bei den Betriebssystemen hatten erst die mit GUI (also allen voran der Macintosh) File-Requester und auch andere, nicht direkt mit Grafik assoziierte Funktionen, wie Cut/Copy/Paste oder beispielsweise auch programmübergreifende Druckertreiber im Angebot. Woher kam das wohl?

    Wohl daran, dass Betriebssysteme mit textbasierten Shells schlicht und einfach keinen Dateiauswahldialog brauchen. Bzw. umgekehrt, dass es (zumindest sehr lange) keinen vernünftigen Standard gab, wie denn eine Anwendung im Textmodus auszusehen hatte (Stichwort: SAA). Das wurde einfach nicht als Aufgabe des Betriebssystems, sondern der Entwicklungsumgebung gesehen.

    Im Prinzip hätten doch auch textbasierte Betriebssysteme, wie MS-DOS oder CP/M solche Funktionen bieten können.

    Gab es, siehe DOS-Shell. Hat nur niemand verwendet. Warum soll ich zuerst die DOS-Shell laden, um dann ein Programm zu starten? Für Anwendungen - siehe oben (SAA).


    Erst mit so Umgebungen wie Turbo Pascal 6.0(?) kam eine Unterstützung für eine einheitliche Oberfläche, wenn man denn wollte.

  • Ja, aber so wie ich das verstanden habe, weiß das Wirts-Programm ja nicht, dass Dolphin-DOS ein Directory über den Screen gelegt hat – keiner der Protagonisten kann/wird also einen Refresh auslösen, oder?

    Aber wie gesagt, kann man auch mit dem Original-KERNAL schon mit den Steuerkommandos den Screen kaputt machen, sobald die Eingaberoutine aufgeruffen wird. Mir sind jedenfalls keine Programme aufgefallen, die da Probleme gemacht hätten.

  • Bzw. umgekehrt, dass es (zumindest sehr lange) keinen vernünftigen Standard gab, wie denn eine Anwendung im Textmodus auszusehen hatte (Stichwort: SAA). Das wurde einfach nicht als Aufgabe des Betriebssystems, sondern der Entwicklungsumgebung gesehen.

    Aber wieso hat sich diese Einstellung deiner Meinung nach (bzw. mit) mit dem Erscheinen der grafischen Betriebssystem verändert? Oft wurde und wird ja so getan, als wäre das nur "Klickibunti" für IT-Weicheier gewesen, die sich keine Befehlsfolgen merken können. In Wirklichkeit wurden mit den grafischen Systemen programmübergreifende Bedien-Standards etabliert, die weit über Maus-Schubserei hinausgingen: Einheitliche Shortcuts, Druckertreiber, File-Requester, Dialoge, Menüstrukturen, Copy&Paste usw. All das gab es vor Mac/Lisa/Xerox nicht und dann wurde das im Zuge der nachfolgenden grafischen Systeme Standard – aber eben nicht vorher, obwohl all das auch ohne Bitmap-Darstellung möglich gewesen wäre. Eigentlich wurde doch mit dem Erscheinen des Macintosh (und natürlich gewissen Vorentwicklungen bei Xerox) neu definiert (bzw. deutlich erweitert), was ein Betriebssystem überhaupt zu leisten hat.


    (ich weiß, ursprünglich ging es in meinem Thread um mein Gemecker über fehlende Directory-Anzeigen im "Öffnen"-Dialog. Aber direkt dazu gibt es ja nicht viel zu sagen außer: "Ja, hast recht" oder "stell dich nicht so an". Aber daraus entwickelt sich gerade eine Betrachtung der Betriebssystem-Geschichte, die ich so noch nicht gesehen habe.)

  • Aber wieso hat sich diese Einstellung deiner Meinung nach (bzw. mit) mit dem Erscheinen der grafischen Betriebssystem verändert?

    Weil da der "Plattformbesitzer" Vorgaben gemacht hat, wie Applikationen aussehen und sich bedienen lassen sollen. Bei den textbasierten Systemen gab es solche Vorgaben (anfangs) nicht, da konnte sich jeder selbst überlegen, wie er seine Benutzeroberfläche baut ohne auf andere achten zu müssen.

  • Bei den textbasierten Systemen gab es solche Vorgaben (anfangs) nicht

    DASS es so war, haben wir ja gesehen. Die Frage ging eher in die Richtung: Warum? Und zudem geht es nicht nur ums Aussehen, sondern ja auch beispielsweise um einheitliche Druckertreiber und Copy&Paste. Warum kam das alles (erst und zusammen) 1983/84 auf den Markt? Warum dachte man vorher, dass das nicht auch die Aufgabe eines mitgelieferten Betriebssystems sein könnte?