Und irgendwann werden mit den Sourcen hier: Bitte melde dich an, um diesen Link zu sehen.
Netzwerk-Apps für GoDos geschrieben! ![]()
Ja, man darf noch träumen!
Es gibt 313 Antworten in diesem Thema, welches 59.478 mal aufgerufen wurde. Der letzte Beitrag (
Und irgendwann werden mit den Sourcen hier: Bitte melde dich an, um diesen Link zu sehen.
Netzwerk-Apps für GoDos geschrieben! ![]()
Ja, man darf noch träumen!
Idee!
Könnte nicht mal einer von euch C-Programmierern einen UI-Builder für GoDot/goDos basteln? Sowas, wo man die 16 verschiedenen Requester anwählen, aufziehen, verschieben, ändern kann, Texte einsetzen, Events zuordnen usw. So ähnlich wie im C64Studio (nur besser...
) Zum Schluss würde man das Ganze als ACME-Datei abspeichern, bereits mit einem Dummy-Header und einer funktionstüchtigen Teste-das-UI-Routine, vielleicht sogar (für Emulator-User) direkt in ein D64, in dem das ganze System schon drin ist.
Wie eine Screenlist aufgebaut ist, kann man Bitte melde dich an, um diesen Link zu sehen. (PDF-Link) nachlesen, wie ein Modul-Header aussehen soll, findet man auf Bitte melde dich an, um diesen Link zu sehen.. Eine Basis-Testroutine sieht so aus:
jmp start
;
; Header an dieser Stelle, siehe Handbuch
;
start ldx #<screenlst
ldy #>screenlst
jsr gd_screen
jsr gd_eloop
leave sec
rts
stay clc
rts
screenlst:
!by $00
!by 0,0,6,3,$d0
!wo stay
!scr "Test@"
!by 4,0,6,3,$c0
!wo leave
!scr "Exit@"
!by $80
Alles anzeigen
Sie erzeugt zwei Buttons, der eine tut nichts (außer blinken, wenn man draufklickt), der andere verlässt das Modul zum Hauptschirm.
Das würde ich mir wünschen! Und es wäre sicher eine super Anstoß-Anwendung für goDos!![]()
Arndt
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.
Der Dateimanager, den du auf deinem Hauptrechner benutzt, zeigt das Zielverzeichnis auch nicht oder nur rudimentär (Name des Zielordners auf einem Karteikartenreiter o.ä.) an - kaum jemand benutzt heute noch Dateimanager mit zwei gleichberechtigten Listern. Man muss das Zielverzeichnis nicht ständig komplett überblicken - es reicht völlig, einen Eindruck zu haben ob das Ziel wirklich das gewünschte Verzeichnis ist. Dieses Konzept nutzen der Windows Explorer,, der Mac Finder, und alle großen Linux-Desktopumgebungen.
Und das habe ich versucht abzubilden: Man kann im Mockup vom Zielverzeichnis Laufwerksnummer und -typ, Partition (falls vorhanden), Header und ID der Disk (bzw Pfad des aktuellen Verzeichnisses) mit einem Blick erkennen, dazu kommen 15 von 16 Zeichen der Dateinamen. Das reicht völlig, um vor einer Kopieraktion zu entscheiden: "ist das das gewünschte Zielverzeichnis?". Wer mehr Infos braucht, klickt in das rechte Fenster und bekommt sofort Volldarstellung - denn das aktive Fenster enthält ja immer alle Informationen.
Die Alternative war "zwei Fenster, die nur Dateinamen anzeigen", was IMHO die deutlich schlechtere Variante gewesen wäre.
ZitatDas Menü müsste kpl. nach rechts verlagert werden und die Ansicht umschaltbar zwischen einem und zwei Fenster (ein "Split" Knopf).
Hm, gute Idee. Ich hab langsam Gefallen an Mockups gefunden, hier ist noch mal eines:
Bitte melde dich an, um diesen Anhang zu sehen.
Wann man das untere Verzeichnis auf die Anzeige von Header bzw. aktuellem Pfad verkleinert (Doppelpfeil nach unten), könnte man auch Laufwerksnamen und Blocks free für beide Laufwerke anzeigen und hätte trotzdem noch Platz für 14 Verzeichniseinträge.
Usability-Problem: Woran erkenne ich das "aktive" Verzeichnis? (an markierte Einträgen, ja - aber was wen "All" anklicke?)
Find ich super ![]()
kaum jemand benutzt heute noch Dateimanager mit zwei gleichberechtigten Listern. Man muss das Zielverzeichnis nicht ständig komplett überblicken - es reicht völlig, einen Eindruck zu haben ob das Ziel wirklich das gewünschte Verzeichnis ist. Dieses Konzept nutzen der Windows Explorer,, der Mac Finder, und alle großen Linux-Desktopumgebungen.
Deshalb kommt nach jeder Installation ein vernünftiger Dateimanager wie Total Commander oder dessen Klon Double Commander auf die Platte.
kaum jemand benutzt heute noch Dateimanager mit zwei gleichberechtigten Listern. Man muss das Zielverzeichnis nicht ständig komplett überblicken - es reicht völlig, einen Eindruck zu haben ob das Ziel wirklich das gewünschte Verzeichnis ist. Dieses Konzept nutzen der Windows Explorer,, der Mac Finder, und alle großen Linux-Desktopumgebungen.
Da muss ich Dich leider enttäuschen. Mache ich über den Total Commander.
Clips hat das mit den Partitionen so geregelt:
Bitte melde dich an, um diesen Anhang zu sehen.
GoDot: So ein Tool könnte ich dir aus dem ElementEditor zusammenklöppeln, ist aber erstmal wahrscheinlich nur ein (im Code) hässlicher Hack ![]()
Edit: Hast du den Zeichensatz irgendwo als binary herumliegen?
Ich glaube ich hab jetzt genug von Mockups, meine letzten drei:
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.
Damit könnte ich auch gut leben. Die Doppelpfeile vergrößern bzw. verkleinern des untere Verzeichnis in zwei Schritten. Anzeige des Laufwerkstyps und der freien Blocks unterhalb des Verzeichnisses wird aus Platzgründen ausgeblendet, wenn der untere Verzeichnisinhalt auch angezeigt wird.
Wobei ich wirklich finde, man sollte erst mal einen Satz Gadgets definieren, den man für Anwendungen braucht - und vor allem eine brauchbare Menü-Lösung. Alleine für den Dateimanager fallen mir folgende Befehle ein, die irgendwie (als Knopf oder Menüpunkt) auf den Schirm sollten:
(die meisten Einträge unter "Disk" könnten externe Module sein, wollte nur den Punkt "Disk" auffüllen
)
Das ist mit den bisherigen Knöpfen und/oder dem "U&I"-Menü nicht zu machen. Eine ständig eingeblendete Menüzeile wie in GEOS/Mac OS etc. würde IMHO vertikal und horizontal zu viel Platz verbrauchen.
Es gibt laut "Inside Godot" 16 Gadget-Typen - das ist aber eigentlich immer das selbe Gadget (ein Knopf), nur in verschiedenen Darstellungen. Alle komplexeren Gadgets (Dateiauswahldialog) werden per Betriebssystemroutine aus diesen Knopf-Gadgets zusammengebastelt - richtig?
Auswahlknöpfe muss man "von Hand implementieren, oder? Muss mich da mal etwas einlesen, ein scrollbares Textfeld mit diversen EIgenschaften (Scrollbars h/v?, Zeilen markierbar? Reagieren auf Doppelklick?) wäre schon ganz nett. Und eben eine (wie auch immer geartete) Menü-Implementation, der man eine komplette Menüstruktur übergeben kann...
Korodny: Wenn Du das Grau etwas dunkler machst wie bei Arndt seine Screens, wäre das toll. Ist schon recht hell ![]()
Hast du den Zeichensatz irgendwo als binary herumliegen?
Ist mit auf der Demo-Disk (mit dem FileCopy): Bitte melde dich an, um diesen Link zu sehen.. Heißt "uni.set"
Ich glaube ich hab jetzt genug von Mockups, meine letzten drei:
Die gefallen mir aber ausnehmend gut!
Da bastele ich mal gleich was.
Arndt
Die gefallen mir aber ausnehmend gut! Da bastele ich mal gleich was.
Oh, das freut mich!
Ist mit auf der Demo-Disk (mit dem FileCopy): Bitte melde dich an, um diesen Link zu sehen.. Heißt "uni.set"
Die gefallen mir aber ausnehmend gut!
Da bastele ich mal gleich was.
Arndt
Die sind in der Tat gut.
Hier mal ein ganz grober Wurf, da sind noch 5000 Buttons/Reiter drin, die keinen Sinn machen. Wenn du unglücklich klickst, kackelt es wahrscheinlich auch ab ![]()
Dazu ein Testprojekt, in dem die Gadget-Typen definiert sind, bitte erstmal nur das Projekt so nehmen bzw. davon kopieren. Im Hauptfenster File->Open und das testproject aufmachen. Dann den ersten Screen auswählen, dort sind zwei Gadgets drauf.
Ist das in etwa, was dir vorschwebt? Du kannst da mehrere Screens definieren, die Gadgets drauf verteilen, rumziehen und -kopieren (Ctrl + Mausklick). Der Export exportiert noch nix Sinnvolles.
Ist das in etwa, was dir vorschwebt?
JA!
So!
Ein paar der Typen waren nicht korrekt, und es wäre schön, wenn die Element-Vorgabegröße auf 3x3 per Default eingestellt wäre. Der Screen sollte von vorn herein in Hintergrundfarbe 12 (oder was hast du da genommen?) sein. Vielleicht geht ja auch Ein-Element-an-den-Ecken-großziehen? ![]()
Wichtig ist, dass die Fenster überlagert werden können (einige Darstellungstricks basieren darauf). Was später zuerst in der Screenlist steht, wird zuerst dargestellt. So kann man dann Container basteln, wo die Texte auch zeilenweise aktiv übereinander stehen.
Arndt
Hier mal ein ganz grober Wurf, da sind noch 5000 Buttons/Reiter drin, die keinen Sinn machen. Wenn du unglücklich klickst, kackelt es wahrscheinlich auch ab
![]()
Braucht das Ding eine bestimmte Version des .NET-Framewarks? Ich habe hier nur XP SP3 unter einer VM, nach der Fehlermeldung, dass "die Anwendung nicht richtig initialisiert werden konnte", habe ich .NET 4.0 installiert, jetzt kriege ich mitgeteilt Windows sei "unable to find a version of the runtime to run this application".
Laut Projekt ist es .NET 3.5.
Die Typen hatte ich nur nach Gefühl nach dem PDF zusammengeraten. Wenn du genau Tabellen für die 8 Zeichen der 16 Teile hast, gerne her damit ![]()
Überlagern ist ja kein Problem, das ist auch genau so, wie gewünscht.
Edit: Hier mal etwas aufgebessert, der Export (Pfad im Export-Reiter einstellen) sollte jetzt eine möglicherweise korrekte Screenlist-Assembly-Datei rausschreiben.
Mist, zu spät zum Bearbeiten. Hier nochmal ein Schub, wenn du in das Zeichen im rechten unteren Eck klickst, kannst du die Größe eines Gadgets verändern.
Die nächsten Versionen schiebe ich auf meine Homepage, muss ja das Forum nicht über Gebühr belasten (dafür sind die Schneeflocken da).
Laut Projekt ist es .NET 3.5.
3.5 war wiederum zu wenig, da hat er sich beschwert dass 3.5 SP1 benötigt wird. Mit der Version klappt es jetzt aber.
Mist, zu spät zum Bearbeiten. Hier nochmal ein Schub, wenn du in das Zeichen im rechten unteren Eck klickst, kannst du die Größe eines Gadgets verändern.
Erster Eindruck: Klasse! Versuche ich einen String für ein Gadget einzugeben, kriege ich für Zahlen und geshiftete Zahlen allerdings nur "ü" angezeigt (in der GUI-Vorschau, nicht im String-Gadget wo ich sie eingebe).
Edit: Vielleicht könnte man auch die rechte obere Ecke greifbar machen (oder gleich alle Ecken)? bei der vermutlich häufigsten Überlagerung - ein Element verdeckt den unteren Rahmen eines anderen Elements - ist nämlich genau die rechte untere Ecke nicht greifbar.
Ach ja, der String. Da hatte ich erstmal nur Leerzeichen und Buchstaben zugelassen, den Rest muss ich noch zuordnen.
Die rechte untere Ecke ist nur für die Größe, alle anderen Zeichen sind einfach verschieben. Die anderen kann ich aber auch umsetzen, ist ja nicht schwer.
GoDot: Passt denn die screen_list so?