Heute so gecodet...

Schau Mal nach wxOverlay

Zitat von drazil

Schau Mal nach wxOverlay

Ahh! Danke für den Tip, das kannte ich noch nicht.

Kannst Du so einen Hintergrund aus Tiles generieren?

Zitat von daybyter

Kannst Du so einen Hintergrund aus Tiles generieren?

Ich muss mir mal diese Overlay Klasse ansehen. Allerdings habe ich einen Thread auf stackoverflow dazu gefunden wo das scheinbar problematisch ist. Das Posting ist zwar 9 Jahre alt, aber im aktuellen Code steht immer noch drin dass dieser Code experimentell ist und nur für interne Zwecke benutzt werden sollte. Klingt also nicht ganz so vielversprechend. Ausserdem hatte ich den Eindruck dass das Overlay auf einen DeviceContext basiert. Das würde dann bedeuten, wenn sich drunter zwei Fenster befinden dann könnte das Overlay gar nicht richtig angezeigt werden.

Das mit den Tiles wäre auch eine Idee. Ich könnte für jedes Controlelement ein eigenes Ownerdraw Fenster aufmachen und passend positionieren.

Ich habe mir das in Visual Studio nochmal genauer angesehen, wie es soch dort verhält und festgestellt dass es gar nicht transparent ist. Das würde das Ganze einfacher machen. Transparenz würde das wohl eher unübersichtlich machen. Nur die Vorschau müsste Transparent sein, aber ich denke das kann man hinbekommen, weil das wiederum immer nur in einem einzelnen Fenster angezeigt wird. Da gibts dann keine Überlappungen.

Ich hab nur gefragt, weil ich mal ein bischen Code geschrieben hab, der einen Hintergrund gebraucht hätte. Also für einen Shooter, wo ein Sprite von unten nach oben vor einem Hintergrund fliegt, und irgendwas abschiessen sollte.

Ich glaub, den Code müsst ich erstmal noch kurz debuggen, aber er hat mal funktioniert.

Gestern habe ich endlich den RRB-Einsatz in Mega Sisters hinbekommen. Damit kann man wunderbare Parallax-Layer zusammenbasteln, oder Sprites simulieren. Das war ein Akt.

Ist eine ziemlich mächtige Technik, aber braucht auch einiges an Planung für das Speicherlayout.

Was bedeutet denn RRB-Einsatz, um hier mal mit Ahnungslosigkeit zu glänzen ?

Wir sind beim Mega65:

RRB steht für Raster Rewrite Buffer. Man kann den Bildschirmspeicher länger definieren als der sichtbare Bereich. Mit bestimmten Werten im Color-RAM kann man dann Zeichen in X versetzt darstellen.

Bei Mega Sisters ist dann der Hintergrund in den linken 40 Zeichen, dann kommt ein Verschiebe-Zeichen, dass die Rasterposition wieder auf 0 setzt. Die nächsten 40 Zeichen werden dann über die bisher dargestellten gezeichnet (Index 0 ist transparent).

Dieser RRB ist eine coole Sache. Will ich mir auch mal ansehen. Damit kann man sowas wie Softwaresprites machen, aber auf einfache und hardwareunterstützte Weise. Man definiert dann einfach einen anderen Zeichensatz aus dem sich dann dein Sprite zusammenstellen lässt, und kann das dann an einer beliebigen Position anzeigen lassen.

Zumindest wenn ich das richtig verstanden habe.

Ja, in etwa. Leider nicht ganz beliebig. In X verschoben geht, in Y weniger gut. Und ich habe gerade gemerkt bekommen, dass man da auch nicht unendlich Layer übereinandern setzen kann. Bei zwei vollen Screens wird es schon eng.

In den letzten Tagen habe ich, wenn ich Zeit hatte, an der Maussteuerung für die Dockinglib weitergerschraubt. Letztens hatte ich ja eigentlich nur quasi einen Proof Of Concept gebaut, und jetzt habe ich die Mausevents erstmal so weit implementiert wie ich sie dann vermutlich brauchen werde. Zumindest den Auslöser habe ich schon mal. Ausserdem kann ich jetzt auch schon das Kreuz anzeigen über dass dann die Dockingposition ausgewählt wird (wie das ja auch bei Visual Studio gemacht wurde). Allerdings habe ich jetzt ein kleines Problem. Vielleicht hat ja jemand Lust mir dabei zu helfen. Ich bräuchte nämlich die Grafiken wie sie hier in dem Screenshot zu sehen sind: Heute so gecodet... und ich bin nicht gerade ein begnadeter Grafiker. Falls also jemand jemanden kennt oder Zeit und Lust hat damit auszuhelfen wäre das super.

Ich habe mir schon überlegt ob ich einfach die Grafiken von dem Screenshot ausschneiden soll, aber ich weiss nicht so recht ob es damit dann Schwierigkeiten geben kann. Falls das Assets sind, die man vom Visual Studio in eigenen Projekten verwenden kann (was ja durchaus sein könnte), dann habe ich sie jedenfalls noch nicht gefunden.

Als ich für mein Dockingmodul das Layout implementiert hatte, habe ich ein kleines Problem gefunden. Da ich zu der Zeit schon keine Lust hatte noch weiter an diesem Teil zu arbeiten und auch mal weiterkommen wollte habe ich das getan was jeder gute Programmierer tut wenn er einen Fehler findet. Ich habe ihn ignoriert und gehofft das er verschwindet. Ich dachte mir, eigentlich ist das ja ein Problem von wxWidgets und geht mich nichts an, also sollen die das fixen.

Das Problem war, dass bei den Splitterwindows der Sash zum verändern der Fenstergrösse in absoluten Pixeln verschoben wird wenn das Fenster verkleinert wird. Diese Situation tritt immer dann ein, wenn der User z.B.ein Fenster aus dem unteren Bereich ruasnimmt und dann links oder rechts wieder andockt (natürlich auch in vielen anderen Szenarien)

Das sieht ungefähr so aus:

Nehmen wir an das wir ein Fenster haben das 800 breit ist und das Fenster ist bei 200 geteilt

Wenn wir dieses Fenster jetzt um 250 Pixel verkleiner, dann verschiebt sich das Handle auf -50, es verschwindet also.

Das hat den unangenehmen Effekt dass bei verschachtelten Splittern (was bei einem Dockyinglayout ständig vorkommt), diese Verschiebung dann auch an die Unterfenster weitergegeben wird damit die ihre Grösse anpassen können. Das Ergebnis ist dass das Layout komplett zerstört wird.

Was ich aber für das Docking brauche ist, dass sich das Fenster zwar verkleinert, das Handle aber noch vorhanden bleibt, so dass die Proprotionen des Layouts erhalten bleiben:

Da ich jetzt die Maussteuerung schon soweit fertig habe dass ich tatscählich Fenster rumschieben kann, hat sich dieser Fehler wieder unangenehm bemerkbar gemacht. Das Ding war unbenutzbar, weil bei jedem Verschiebevorgang das Layout immer wieder zerstört wird. Kein User würde so ein Programm verwenden wollen. Also habe ich zähnknirschend angefangen den Code nochmal anzusehen um eine Lösung dafür zu finden. Meine ersten Versuche waren recht aufwändig, aber dann habe ich überlegt das direkt in die wxWidgets Klasse einzubauen und das ging dann doch ganz leicht, mit einer minimalen Anpassung und jetzt funktioniert es echt super. Das finde ich jedenfalls echt toll, dass ich bereits mit meinem eigenen Dockingcode die Fenster rumschieben kann und sehen kann das mein Konzept aufgeht. Immerhin war ich da anfangs nichtmal sicher, ob das wirklich so funktioniert wie ich mir das vorstelle. Ich habe dabei zwar noch einen anderen Fehler in der Library gefunden, aber wie schon oben gesagt, den kann man ignorieren. Na, zumindest kann ich um den Herumarbeiten ohne dass es dabei zu Problemen kommt.

Das Docking ist zwar noch nicht fertig, aber es nimmt bereits Gestalt an. Also hoffe ich mal, das ich dann die erste Version in meinen Debugger einbauen kann um dann endlich daran weiter arbeiten zu können.

Ordentliches Docking ist cool

Schaffst du es auch, das Layout abzuspeichern und wieder herzustellen? Das ist meines Erachtens eines der noch nicht sauber gelösten Probleme bei der DockPanelSuite die ich im C64Studio verwende. Das kann ja böse verschachtelt werden; plus es gibt pro Fenster auch noch immer zwei Zustände, Docked und Floating.

Was macht man, wenn die Auflösung beim Wiederherstellen einige Positionen nicht mehr erlaubt? Etc

Zitat von Endurion

Ordentliches Docking ist cool

Ja. Ich warte seit ca. 15 Jahren drauf dass das in wxWidgets kommt. Jetzt habe ich es selbst in die Hand genommen.

Zitat

Schaffst du es auch, das Layout abzuspeichern und wieder herzustellen? Das ist meines Erachtens eines der noch nicht sauber gelösten Probleme bei der DockPanelSuite die ich im C64Studio verwende. Das kann ja böse verschachtelt werden; plus es gibt pro Fenster auch noch immer zwei Zustände, Docked und Floating.

Das Speicher und wiederherstellen ist geplant für Phase 3.

1. Phase war die LayoutAPI

2. Maussteuerung für das eigentliche Docking

3. Komforfunktionen wie Events, Laden, speichern, etc.

Bei Speichern wird ja der Zustand gespeichert. Ob das Fenster Floating war oder eben Teil eines Layouts ist dabei egal. Ich habe geplant, dass der User (Entwickler) eine Callbackfunktion angeben kann. Das Speicher funktioniert so dass ein String erzeugt wird, in dem dann alle wichting Informationen gespeichert werden. Ich fange beim Hauptfenster an und gehe dann alle Childs durch. Dabei speichere ich die relativen Positionen. Also z.B. das Fenster ist rechts vom vorherigen, damit ich es wieder andocken kann. Die Grösse und andere Infos werden auch abgespeichert, wobei die Grösse nicht ganz so wichtig ist, da beim Wiederherstellen die Grösse anders sein kann. Das Gleiche Feature kann man übrigens auch dafür verwenden um verschiedene Views zu erstellen die der Anwender dann abrufen kann (sofern das implementiert wird). Dann kann man z.B. ein Layout erstellen, das unter einem Namen speichern, ein weiteres Layout erstellen und dann zwischen den beiden umschalten (Also z.B. Coding View und Debug View). Die API gibt das her da ich ja nicht unterscheide zwischen Speichern/Laden vom Programm beim Start oder zu anderen Zeitpunkten. Das ist dann halt Aufgabe des Entwicklers, wie er diese Features benutzt.

Verwendest du wxWidgets im C64 Studio? Mit dn wxAUI Klassen?

Zitat

Was macht man, wenn die Auflösung beim Wiederherstellen einige Positionen nicht mehr erlaubt? Etc

Beim Wiederherstellen werde ich ebenfalls eine Callbackfunktion aufrufen. Damit kann der Entwickler beeinflussen was beim Wiederherstellen passieren soll. Ich speichere ja nur die Positionen ab. Über den Callback beim Speichern kann der Entwickler dann eigenen Infos mit abspeichern. Die kann er dann beim Laden benutzen um alles wieder richtig herzustellen. Das ist auch Notwendig, da ja z.B. manche Fenster gar nicht existieren müssen wenn wiede hergestellt werden. Die müssen dann ja erst erzeugt werden um das Layout wieder herzustellen.

Als Beispiel nehme ich mal meinen geplanten Debugger. Beim Speichern zeige ich verschiedene Fenster an wie z.B. einen Memorydump, Assembler, etc. Da will ich beim Wiederherstellen auch in der Lage sein, die aktuelle Position im Speicher abzuspeichern, oder bei einem Sourcefile halt den Filenamen, so dass man eben alles wiederherstellen kann wie es vorher war. Das ist aber halt Aufgabe des Entwicklers, denn die API kann solche Dinge natürlich nciht wissen, das ist Applikationsspezifisch.

Die Auflösung spielt dabei eigentich keine Rolle. Das Layout stellt ja keine absoluten Positionen her, sondern nur relative. Wenn sich die Auflösung geändert hat, dann werden die Fenster halt entsprechend kleiner (oder grösser), aber das Verhältniss sollte das Gleiche bleiben. Als Anwender will ich ja eigentlich sehen dass meine Fenster wieder alle wie vorher da sind, mit den gleichen Einstellungen und in der gleichen Anordnung.

Wenn mein Docking fertig ist, werde ich es sowieso als erstes in meinen Debugger einbauen. Im Moment habe ich nur ein Testprogram, aber bevor ich das auf die Welt loslassen kann, sollte es wenigstens mindestens ein echtes Programm geben, dass es benutzt. Da werde ich sowieso noch genug Probleme finden die es zu fixen gilt.

Falls du wxWidgets verwendest und das dann ausprobieren willst, kannst du die Version dann ja probieren. Dann hätte ich schon mal einen weiteren Tester der mir Feedback geben kann. Das Projekt ist eh auf Github, aber im Moment muss man halt noch meinen eigenen wxWidgets Fork verwenden. Ich hoffe ja dass die das dann in den Mainbranch übernehmen. Aber das dauert sowieso noch. Erstmal Featurecomplete werden und eben in einer echten Anwendung testen.

Ich benutze Windows.Forms in C64Studio, dafür gibt es die DockPanelSuite. NuGet package laden, Library verwenden, fertig

Die haben auch so Events für's Wiederherstellen. Da gibt es ja auch das Problem, dass das Docking zwar weiß, dass da ein Fenster ist, aber die zu erzeugende Klasse ist von einem Fenster abgeleitet, etc.

Die packen das auch in einen String

Zitat von Endurion

Ich benutze Windows.Forms in C64Studio, dafür gibt es die DockPanelSuite. NuGet package laden, Library verwenden, fertig

Die haben auch so Events für's Wiederherstellen.

Die packen das auch in einen String

Ja, bei wxAUI ist das auch so. Die Idee fand ich ganz gut, deshalb werde ich das so beibehalten. Das lässt sich dann schön kopieren oder speichern und man hat kein Problem mit irgendwelchen Formaten. Das schöne ist dass man den String dann auch einfach in ein anderes INI File übernehmen kann und sein eigenes Layout wieder bekommt wenn man auf eine anderen Computer wechselt.

Das kann dann in etwa so aussehen:

Zitat

Da gibt es ja auch das Problem, dass das Docking zwar weiß, dass da ein Fenster ist, aber die zu erzeugende Klasse ist von einem Fenster abgeleitet, etc.

Deshalb will ich dafür eine Callbackfunktion verwenden. Wenn das Framework dann ein Fenster benötigt dann ruft es den Applikationscode auf und der kann dann dafür sorgen dass das richtige Fenster erzeugt wird. Das Framework hat ja davon keine Ahnung da das ja zur Applikationslogik gehört.

Das nächste cc1541-Release steht vor der Tür mit Unterstützung für die neueste Transwarp-Version. Bei der Gelegenheit habe ich eine Undelete/Unformat-Funktionalität eingebaut, die anhand von gelöschten Directory-Einträgen oder (optional verstümmelten) Track/Sektor-Ketten auf der Diskette Dateien wiederherstellen kann. Die Hoffnung ist, dadurch noch ein paar Datenschätze auf archivierten Diskettenimages zu finden.

Hallo zusammen,

ich habe in den letzten Tagen ein Tool geschrieben, was mir eine TOSEC Datei entpackt und das Ergebnis ist eine definierte Verzeichnisstruktur kopiert. Also nix besonderes.

Ich wollte mal wieder mein C64 mit dem UII verwenden um ein paar Demos oder Games zu spielen, aber meine tolle SD Karte ist damage. Um jetzt nicht alle Files per Hand zu entpacken und in den entsprechenden Ordner zu kopieren habe ich eben das Tool geschrieben.

So sieht das Ganze aus:

Mit Hilfe der Einstellungen kann man bestimmen wie der Name, welcher auf der TOSEC Namenskonversation beruht, erstellt werden kann. Auch kann man eine Ordnerstruktur erzeugen lassen.

Bei der Gelegenheit habe ich auch per Default alle alternativen und fehlerhaften Einträge deaktiviert. 😉 Aber hier mal die Einstellungen:

Es war auch mal wieder eine Übung mit C# und MVVM.

Gruß

pepe

Mittlerweile funktioniert schon ein Teil des dockings. Das finde ich echt geil, ich kann die ganze Zeit mit meiner Demoapp rumspielen.

Es sind noch ein paar rauhe Ecken die ich noch ausbessern muss, aber zumindest das docken von Splittern funktioniert recht gut. Wenn ich die aktuellen Kleinigkeiten ausgebessert habe kommen dann als nächstes die TabControls dran. Bei den TabControls gibts im Prinzip zwei wesentliche Situationen die man unterscheiden muss.

1. Der User kann einen Tab nehmen und den hin und herschieben, so dass der Tab an eine neue Position rückt, aber im Control drin bleibt.

2. Der User kann ein Fenster von draussen in den Tab reinschieben, oder einen Tab nehmen und rausschieben.

IMO ist eigentlich nur Punkt 2 echtes Docking. Der erste Punkt wäre eigentlich ein Kandidat der im wxNotebook direkt reingehört. Immerhin würde das auch die generelle Userexperience verbessern, unabhängig davon ob jemand das Docking verwendet oder nicht. Andererseits macht das aber meine Arbeit erstmal komplizierter, weil ich eigentlich keine Controls von wxWidgets verändern wollte. Die Hilfsfunktion für den Splitter war unbedingt notwendig, die musste direkt im wxSplitterWindow behoben werden. Das Steuern kann ich allerdings auch "von aussen" machen, was erstmal einfacher ist. Schlimmstenfalls muss ich das dann in das wxNotebook verschieben. Das Gleiche gilt übrigens auch für die wxToolbar. Solche Features frei anordenbare Ribbons (heissen die so?) gibts da auch nicht und muss ich auch mit einbauen.

Mal sehen was die wxWidgets Entwickler sagen, wenn ich dann irgendwann den Pullrequest zur Aufnahme stelle. Ich weiss sowieso noch nicht, ob die mein Docking überhaupt nehmen werden. Einerseits wir das wxAUI kaum gewartet weil sich da scheinbar keiner findet (und es ist auch nicht gerade einfach). Andererseits weiss ich nicht ob sie dann zwei verschiedene Systeme für die gleiche Funktionalität haben wollen. Ich bin zwar der Meinung dass meine Implementierung besser ist, weil sie viel generischer ist und vor allem auch entsprechende Events zur Verfügung stellt, so dass man so ziemlich jeden Teil des Dockings in seiner eigenen Applikation anpassen kann wenn man das will. Anderereseits haben die wxAUI Klassen auch Vorteile, weil sie einige Sachen bieten die ich nicht habe, z.B. sowas ähnliches wie Themes.

Auf jeden Fall habe ich die Klassen schon ein wenig auf die Codingguidelines vorbereitet so dass ich dann hoffentlich nicht zuviel ändern muss. Worst Case wäre allerdings wenn sie nicht mal meine Splittererweiterung annehmen würden. Das würde dann bedeuten dass ich das Docking nichtmal als externes Projekt einbinden könnte, sondern meinen eigenen Fork betreiben müsste, was ich auf keinen Fall wollen würde.

Was ich auch noch angefangen habe ist, dass ich die Funktionen aufteilen muss. Spätestens wenn ich die Events einbaue, muss der Code sowieso modularer werden, aber derzeit sind die Funktionen echt RIESIG. So programmiere ich normalerweise nicht, weil das schlecht wartbar, unübersichtlich und kaum wiederverwendbar ist. Bei einigen der neueren Funkktionen habe ich das schon gemacht, aber es wartet noch einiges auf mich. Im Moment will ich mich aber mehr auf die Funktionalität konzentrieren damit ich da endlich vorankomme und was nutzbares habe.

Endlich ist es soweit! Mein Konzept funktioniert so wie es geplant war und ist jetzt (fast) fertig. Das finde ich sowas von geil!!!! Ich habe zwar noch einen Bug gefunden den ich morgen dann fixen werde, und es fehlen auch noch einige Features (Floating windows, Toolbar support, Serialisierung und Events), aber das Grundgerüst steht jetzt und ich habe ein voll funktionsfähiges Dockingmodul.

Binnoch unschlüssig was ich als nächstes angehen soll. Eigentlich muss ich einige der Funktionen noch überarbeiten (langweilig) weil die im Moment nicht sonderlich schön sind. Wichtig wäre es jetzt die Events einzubauen, aber dazu muss ich auch die Funktionen überarbeiten, das würde dann Hand in Hand gehen. In den meisten Fällen kann ich anhand der Mausposition erraten wo das Docking stattfinden soll. Allerdings gibt es zwei oder drei Fälle bei denen ich das nicht erkennen kann. Wenn die Maus am Rand eines Fenster ist, dann ist es eigentlich klar, was gemeint ist. Wenn die Maus aber mitten in einem Fenster ist, dann kann das bedeuten dass der User vielleicht garnicht docken will und es sich anders überlegt hat (so behandle ich das jetzt im Moment weil es am einfachsten ist). Es kann aber auch bedeuten dass er das Fenster herauslösen will und Floating haben will. Oder aber es könnte bedeuten dass er das Fenster in en Tabcontrol umwandeln will und dann mehrere Fenster gemeinsam in dem Tabcontrol hat (so wie bei Visual Studio wenn man mehrere Sourcen offen hat). Um das zu unterscheiden muss ich dann GUI Elemente einblenden für Tab oder Float und wenn keines der beiden ausgewählt wird, dann war es eben Cancel. Das werde ich dann noch demnächst angehen. Einerseits würde ich gerne schon die volle Dockingfunktionalität abgeschlossen haben bevor ich die Events mache, andererseits muss ich die Teile dann für die Events sowieso nochmal anfassen, auseinanderreissen und neu zusammensetzen. Und immerhin habe ich durch die Konzentration auf die Kernfuktionalität doch noch einige Bugs gefunden.

Das Schöne an dieser Lösung ist dass sie (fast) ohne Eingriffe in wxWidgets selbst funktioniert. Für wxAUI gibt es einen Haufen neuer Klassen die man lernen muss und die im Wesentlichen Kopien von bereits bestehenden Klassen sind. z.B. gibts ein wxAUINotebook das genau das gleiche macht wie das normale wxNotebook nur halt um das Docking erweitert ist. Bei meiner Lösung kann der Entwickler die bestehenden Komponenten ganz normal weiterverwenden und muss nichts neues lernen. Wenn man das Docking verwenden will, ist der einzige Unterschied dass man einen anderen Frame verwendet und die Objekte an diesen schickt, statt sie selbst anzuordnen. Wenn man aber will, kann man alle Elemente des Dockings durch die Events selbst anpassen und z.B. andere Effekte verwenden um die Dockingziele anzuzeigen.

Bisher habe ich nur zwei Erweiterunge benötigt. Das eine ist für die Splitter. Da habe ich ein neues Event benötigt, welches die Handles richtig berechnet, wenn sich die Fenstergrösse verändert. Das ging in der Form bisher nicht. Da habe ich auch schon einen PR gemacht gegen wxWidgets der wohl auch akzeptiert wird, weil das ja eine allgmeine Verbeserung ist, die nicht nur für mein Docking nützlich ist. Die zweite Erweiterung ist, dass man sich die Grösse eines Tabs holen kann. Das ging bisher nicht. Auch das ist eine allgemeine Verbesserung, daher rechne ich damit dass die auch problemlos aufgenommen wird.

Allerdings ob das Docking selbst aufgenommen wird weiss ich noch nicht. Einer der Entwickler meinte dass man wohl kaum 2 verschiedene Dockingsystem haben will und es schöner wäre wenn ich stattdessen wxAUI verbessert hätte. Das hatte ich auch versucht und wochenlang Probleme gefixed, bis ich dann an einen Punkt gekommen bin wo es nicht mehr weiterging ohne gravierende Änderungen, die dann wohl auch nicht mehr Sourcekompatibel geblieben wären. Und an der Stelle habe ich dann abgbrochen und beschlossen mein eigenes Ding zu machen. Na, ja. Wenn meinen Ändereungen akzeptiert werden, dann kann ich wenigstens das Docking als seperates Projekt anlegen, das wäre zwar nicht so schön, aber würde problemlos funktionieren. Einen vollständigen Fork würde ich nicht so gerne betreuen müssen.

So, ist etwas lang geworden und ich weiss nichtmal ob das jemand bis hierher durchgelesen hat, aber das Wichtigste stand ja schon ganz oben.