Dann kleiner Kinotip:
Flutsch und Weg. Ist ein schöne (gerenderte) Komodie. Einfach mal den Trailer anschauen



Da war ein Smilie dahinter


Weil man sich dann wieder auf was festlegt. Ansonsten habe ich nichts gegen Streams, benutzte sie nur kaum da ich meine Daten meistens irgendwie im Speicher habe


Lieber nicht. Natürlich könnte man über SDL nen Fallbackmodus machen, aber ansonsten sollte die GUI einfach davon ausgehen, dass schon ein aktivierter Renderkontext und ein initialisiertes Schriftsystem existiert. Ansonsten fliegen halt dem Programmierer NULL-Pointer um die Ohren.
Wir können da doch einfach sagen, dass die Zielgruppe OpenGL-Programmierer/Anfänger sind. Und die sollten schon das VCL-Template am laufen haben.


Mir geht es da eher darum, dass ich nicht will, dass jemand die GUI ausbaut und danach verkäuft oder ähnliches ohne den Code zur Verfügung zur stellen. Wenn jemand an der Basis weiterarbeitet und sie verbessert hätte ich gerne diese Verbesserung. Wegen eines Anfängers würde ich mir da keine Sorgen machen, da er entweder auf der Basis des Konzeptes versucht etwas eigenes zu entwerfen oder eine eigene Komponente entwirft. Bei letzteren wird er vermutlich das ganze veröffentlichen um die Annerkennung zu bekommen.
An sonsten könnten wir auch den Code unter mehrere Lizenzen stellen, sodass sich der Entwickler es sich aussuchen kann welcher er nimmt.

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Dual Lizensen sind eigentlich nicht mein ding.
Meine Idee wäre dann folgenden.
Nicht komerzieller gebraucht: Der Nutzer hat jede änderung des Codes, den Entwicklern mit zu teilen(und die Entwickler entscheiden ob der Code verlangt wird).
Komerziell: Der Nutzer hat entweder darauf hin zu weisen, von wen die GUI kam oder den Regeln für nicht komerzielle dinge zu akzeptieren.

Der User soll einfach eine Email schreiben, in der er beschreibt was er geändert hat.
So kann man dann entscheiden ob man den Code sehen will oder nicht.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Hallo Ihr beiden,

Huch ein Scherz!


Damit kann ich leben.



Ich wiederhole die folgenden Änderungen zum Einarbeiten:

1) Delphi erst ab Version 5
2) XML und binär laden/speichern
3) Die Streams fliegen raus (was nicht bedeutet, dass man sie nicht verwenden darf, sondern dass man sie nicht verwenden muss)

4) Es soll einen Fallbacklevel geben (SDL?), - daraus hab ich jetzt geschlossen, dass OpenGL doch auch gewrappt werden soll?
@edit: ich verbessere mich: I0n0s sagt eindeutig, es soll KEINEN Fallbacklevel geben. Man könnte ja ein Template von DGLSDK verwenden. (Mann, ist gar nicht so einfach, die Übersicht zu behalten, habt Nachsicht mit einer alten Frau)

5) Eine Lizenz wie die oben von Tak vorgeschlagen ist einzuarbeiten (möglichst eine dies schon gibt, wenn das nicht möglich ist, eine Formulierung hinzufügen)

Hab ich was vergessen?
Oh ja, ich hab was vergessen: Es gibt etwas, das ich überhaupt nicht abschätzen kann. Weiß jemand, ob wir Schwierigkeiten mit Net oder Mono kriegen werden? Hoffentlich nicht.

Traude

Ich habe jetzt alles eingearbeitet. Der Abschnitt, der die Voraussetzungen für den Betrieb beschreibt, ist ziemlich dünn. Naja.
Habe jedenfalls meine obige Frage bezüglich Mono/Net noch hinzugefügt.


Das gefällt mir nicht. Würdest du so einen Code verwenden wollen? Die Schrift kann er prüfen, denn wenn was schiefgeht, muss die Funktion, die das Schriftobjekt zurückgibt, ja "Nil" abliefern. Und wenn keine Ereignisse kommen, kommen eben keine. Ob eine Grafiklibrary initialisiert wurde, kann ja wohl irgendwie dem GUI übergeben werden.

Das ist, soweit ich das alles absehen kann, MEINE letzte Bitte: Nehmen wir bloss eine einfache Kontrollmöglichkeit auf, zu überprüfen, ob die GUI zeichnen kann, wie auch immer, etwas, das man im Debugger sehen kann, zB. die Übergabe einer Zahl beim Erzeugen des GUI-Objekts, und Null ist ein Fehlerfall oder sowas (ich arbeite wo immer es geht immer mit Gürtel UND Hosenträger).

Die Fragen in Punkt 8 kann man leicht auf die lange Bank schieben. Sie sind nicht das erste, worum man sich kümmern muss.
Wenn wir uns nun noch darauf einigen könnten, der GUI eine einfache Kontrollmöglichkeit über ihre Lauffähigkeit einzuräumen, sind für mich damit alle primären Unklarheiten beseitigt.

Anbei das geänderte Dokument:

Das aktuelle Dokument sieht gut aus.
Das mit der Font ist soweit in Ordnung, langfristig könnten wir vielleicht ne billige Fallbackschrift einbauen, aber wenn wir uns nicht übernehmen wollen verlangen wir einfach, dass ein Schriftsystem existiert und initialisiert ist. Halt das was in der Dokumentation steht.
Die Lizenz ist soweit dann auch ok. Aktuell würde ich das Dokument als Basis für unser weiteres vorgehen nehmen.

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Was genau kann Delphi4 denn nicht? Das ist nach wie vor meine Lieblingsversion.

@i0n0s:
ich hab das glaub ich nicht erwähnt, aber ich habe sowohl eine Font (eigentlich zwei: eine Texture-Font und eine TTF-Font, beide keine besondere Augenweide, aber dafür mit der Fähigkeit ausgerüstet, selektierte Teilstrings darzustellen ) als auch eine Textur parat, ich hatte ja die TinyGUI schon mal begonnen und bin daher für solche Dinge ein bißchen ausgerüstet. Schliesslich ist es lt. Vorgabe Pflicht, ein Demoprogramm beizustellen.

Ähem, die Fonttextur der TextureFont war von Sulaco. Dort müsste ich mal nachfragen, ob wir das hier verwenden dürfen. Wenn er das nicht will, kann man mit einer freien TTF-Font eine FontTextur pinseln, sollte kein Problem sein. Der Code dazu ist gänzlich von mir, ohne irgendeine Vorlage. Der Code für die True Type Font ist mit Hilfe von Deinem Code aus dem EasySDL, aber prinzipiell selbst geschrieben. In diesem Fall muss ich Dich fragen, ob Du einverstanden bist.

@The-Winner:
i0n0s schrieb:


Traude

Zu der Fonttexture:
Jan Horn kannst du nicht mehr fragen
Ansonsten ist im Bombermantutorial von Sascha ein Tool zum Erstellen dieser Bitmaps verlinkt.
Und die TTF-Font erzeugt ja auch so eine Texture die man nur abspeichern müsste

Die Fallbackfont sollte aber auch ohne Texturen gehen und daher das ganze aus Arrays auslesen oder so. Alle anderen Techniken sind hier schon zu "hightech"

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Nachdem zumindest einer mein gestriges Geschreibsel für gut befunden hat, schiesse ich heute ein TGUI-Item-Basiselement nach. Ich habe versprochen, dass das bis Freitag Abend (also heute) fertig sein wird, aber ich fürchte , dass ich heute Abend - zumindest am frühen Abend - nicht da sein kann, daher schicke ich es jetzt schon.

Das Basiselement erhebt keinen Anspuch auf Vollständigkeit, ich möchte nur demonstrieren, wie ich mir das vorstelle. Ich habe ein wenig bei Delphi und SDL nachgesehen und habe dann versucht, das Ding so einfach und funktionell aufzusetzen, wie es mir möglich war.

Es sind enthalten: Die Vorgabe(unveränderter Text) und eine Delphi-Unit mit einem Objekt namens TGUIItem und ein paar nötigen Zutaten.

Wohl bekomm's!

Ganz böse und ich finde diese Variante auch schon in SDL.pas richtig schlecht.
Das verbraucht viel Code, ist langsam und macht den Code unverständlicher.
Da ist das folgende wesentlich besser und selbst da hab ich noch zu mäkeln .
TKeyDownEventHandler = Procedure (Key: Word; SecondKey: Word;) Of Object;
Vorallem gehst du davon aus, das man eine Methode übergibt und nicht eventuell eine Funktion.
darin sehe ich kein Sinn, was soll dies bewirken ?
Die letzten beiden sind sinnlos, da dies über die Klassenevents schon geregelt wird und die erste funktion gehört definitiv nicht in die klasse. Die Erstellung von benötigten GUIItems macht man in create und welche die zur laufzeit hinzu sollen machen andere Klassen, wie z.B. der Manager oder XML Loader.
Die Properties solltest du noch in den published bereich verschieben.
Des weiteren sollte man noch eine Nr. oder namen für funktionen von Scripten mit einbauen.
Ein Identifier für XML und Script sollte auch rein, sowie top, left, borderleft,bordertop,borderright,borderbottom, allowdrag.

Da sind noch einiges mehr aber dafür hab ich keine Zeit mehr, ich melde mich heute spät abend oder morgen nochmal.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Kann mich da TAK auch nur anschliessen:
Das Eventhandling in der Form nicht gerade toll.

Die ID existiert übrigens schon: FName

FGUIItem sollte bitte eine List und kein Array sein. Ein Array ist hier einfach zu viel Verwaltungsaufwand für ein paar Pointer (wegen Speicherkopieren etc).

Ich würde da einfach empfehlen, dass du dir XD_GUI_Widget anschaust und das entsprechend anpasst, sodass es deinen Wünschen entspricht, dort sollten die wichtigsten Funktionen schon vorhanden sein.

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Das ist ein varianter Record. Variante Records sind erfunden worden, um Datenstrukturen kompakt und klein zu halten. Ich verwende ihn ja dazu, um ein Event zu übergeben, und das muss viel enthalten können. Der variante Record hilft mir dabei, die Daten eben kompakt und klein zu halten.
Daher kann ich das Argument, dass es viel Code verbraucht. nicht akzeptieren.
Der Code ist langsam: kannst Du das näher erläutern?
Er unterscheidet sich von anderen Records dadurch, dass man abfragen muss, um welches Ereignis es sich handelt. Aber um diese Abfrage kommt man ohnehin nicht herum.


Der Code ist unverständlich: gerade in dieses Codestück habe ich viel Mühe investiert, um es übersichtlich zu machen. Tatsächlich halte ich ihn für unschlagbar, was diese Aufgabe angeht. Ich wüsste nichts besseres. Man muss der GUI ein Event übergeben. Wie soll man das schaffen, bei den vielen unterschiedlichen Events? Ich halte den varianten Record für diese Aufgabe sehr gut geeignet. Aber wenn mir jemand etwas geeigneteres empfehlen kann, kein Problem.






Soweit ich weiss, sind Methodenzeiger und prozedurale Zeiger nicht kompatibel. Man müsste sich daher entscheiden, welchen man nimmt. Ich habe die Vorlage mit Methodenzeigern versehen, weil die Vorgabe OOP war. Und ich habe hierbei bei Delphi "abgespickt". Wenns dabei darum geht, dass es für Free Pascal besser wäre, Prozedurzeiger zu nehmen, solls mir recht sein.





Dieser Code ist im Zusammenhang mit der Methode "DeliverEvent" zu sehen. Wenn das Parent weiß, welches seiner Children den Focus hat, kann es das Event direkt an das richtige Child übergeben, ohne lang herumsuchen zu müssen. Das spart Zeit.



Ich verwende für die Ereignisbehandlungsmethoden des GUI-Elements die gleiche Methodik wie für die Ereignisbehandlungsmethoden der aufrufenden Anwendung. Schien mir übersichtlicher zu sein.
Zur Methode DeliverEvent habe ich oben schon was gesagt. Diese Methode, Events zu behandeln ist eine andere als in der XD-GUI. Mir gefällt diese besser.

Und AddGUIItem ist eine Funktion, die das gerade erzeugte Item zurückgibt und die ich nur als Beispiel aufgeführt habe. Das soll später so aussehen:
MyButton:= AddGUIButton(TGUIButton,....).
Und dann ist z.B.möglich: MyButton.Color:= Red;
Ich finde das ganz praktisch, man kann das erzeugte Element im Programm manipulieren. Das jeweilige GUI-Element wird vom Parent erzeugt.

Die Erzeugung von GUIItems kann man auch im Loader machen,ja. Aber auch hier muss das GUI-Element von seinem Parent erzeugt werden, so steht es ja im luftleeren Raum. Die ganze GUI-Mischpoche ist ein Baum, angefangen vom GUI-Manager, der sein(e) Fenster erzeugt, die wiederum ihre Kindelemente erzeugen usw. Aber wurscht wo, erzeugt werden sie in diesem Konzept immer mit einer "AddElement"-Methode, aufgerufen vom Parent.



Wegen der Laufzeit-Typ-Info, meinst Du.OK.



OK.
Wobei ich immer wieder gesagt habe, dass ich beim Skript unterstützung brauche.
Ich schätze außerdem, da werden noch ein paar Variablen mehr gebraucht werden. Allerdings wollte ich jetzt noch nicht alles hineinschreiben, es ging hier mehr ums Konzept.

Traude

@I0n0s:
Ich kann gerne für die GUIItems Listen verwenden, allerdings erst NACH Programmfertigstellung. Denn zum Deguggen sind Listen entsetzlich, weil man den Inhalt nicht sehen kann, den Inhalt von Arras hingegen schon.
Zum Eventhandling habe ich im vorigen Beitrag schon etwas gesagt.

Ich werde nicht einfach die XD-GUI anpassen. Dies ist ein Entscheidungsfindungsprozess, und ich habe oben ein paar Anmerkungen dazu gemacht. Was tun wir, wenn wir uns nicht einigen können?

Traude.

Statt deliverevent, gibt es ja auch schon TObject.Dispatch(var Message) und TObject.DefaultHandler(var Message) .

Dazu steht in der Delphi-Hilfe: "Der Typ TMessage wird für eine Windows-Botschaft verwendet."
Scheint mir ein Windows-Konstrukt zu sein.

Definition des Typ TMessage in der Unit "Messages", Exzerpt aus der Delphi-Hilfe:

Delphi-Syntax:

type
TMessage = packed record

Msg: Cardinal;
case Integer of
0: (
WParam: Longint;
LParam: Longint;
Result: Longint);
1: (
WParamLo: Word;
WParamHi: Word;
LParamLo: Word;
LParamHi: Word;
ResultLo: Word;
ResultHi: Word);

end;

Noch so ein varianter Record.

@zum letztenmal edit: SO einen Record möchte ich bestimmt nicht verwenden.