Der Weg soll folgender sein.
Der User Erstellt ein AppWindow,dieses enthält alle Daten zur Zeichenfläche und enthält auch das Theme und Canvas.
Ich kenne mich nicht mit opengl und vcl so gut aus, da ich es langsamer ist und von delphi abhängig ist.
Wenn ich mich recht erinner besitzt jede Zeichenkompo ein Handle und diese muss man dann dem AppWindow geben und die ausmaße noch dazu. Den Context und so weiter soll aber von der GUI verwaltet werden.
MfG TAK2004

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

Projekte: https://github.com/tak2004

Genau das will ich aber nicht. Es ist mein Kontext und die GUI brauch den Kontext auch nicht wirklich.
Und könntest du den Satz hier nochmal neuformulieren:
"Ich kenne mich nicht mit opengl und vcl so gut aus, da ich es langsamer ist und von delphi abhängig ist."
Ergibt aktuell noch keinen richtigen Sinn.

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

Auch wenn ich sehr lange hier nichts geschrieben hab, aber die Verwaltung des Kontext durch die GUI würde die ganze Kapselung über den Haufen werfen. Dann hätte man sich die viele Arbeit nicht machen müssen.

_________________
(\__/)
(='.'=)
(")_(")

Das GUI hat auch den Anspruch, Programme zu bedienen, die keine Spiele sind. In diesem Fall braucht es JEDENFALLS einen Rendering Context. Die Canvas muss dem GUI alles bieten, was man zum Zeichnen/Texturieren braucht. Wir haben dabei gar keine andere Wahl. Wie sonst sollten wir das machen? Und soll man dann die Fähigkeiten der Canvas einfach brach liegen lassen? Das wäre doch Verschwendung. Wir bieten daher dem Programmierer die Canvas zum Benutzen an. Das ist nicht als Bevormundung gemeint, sondern als Service. Du bist herzlich dazu eingeladen, die Canvas mitzugestalten. Über die Existenz der Canvas bin ich nicht bereit, zu diskutieren, denn einen Rendering Context brauchen wir.

@Evil: Wir machen es ganz ähnlich der VCL. Die VCL ist gut gekapselt. In unserem Konzept ist alles "dicht", obwohl wir Wrapper verwenden. Die Wrapper sind eine GUTE Methode, auf eine Graphic Library zuzugreifen. Und das Zugreifen auf eine Graphic Library steht in unserer Vorgabe, das ist etwas, was die Community entschieden hat.

Traude

Naja man kann ja neben TDGL_AppWindow noch ein TDGL_blakeks machen, welches selber kein Context erstellst sonder einfach nur ein Container ist.
Dann würde es alles erlauben, Fenster von der GUI oder auch Fenster von ausserhalb.


Klar.
Ich hab früher mal mit VCL und OpenGL experimentiert und daraus folgte die Schlussfolgerung, langsam und von delphi abhängig.
Dies ist aber so langer her, dass ich kaum noch ahnung hab wie das genau alles funktioniert hat.

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

Projekte: https://github.com/tak2004

Canvas? Was für ein Canvas den bitte?

Ich hätte hier eine wunderbare Engine, die alles mögliche mit dem von mir erstellten Fenster anstellen kann, sowas wie an den Rand des Fensters kleben, in Tray minimieren etc. Wieso sollte ich das wegschmeissen wenn ich euere GUI nutzen will?
Der grösste Teil der User hat schon einen Renderkontext. Daher müsst ihr dies bedenken so wie ich das oben geschrieben habe...

Aber aktuell sieht es so aus, dass ihr es nicht macht und daher schreie ich hier.

Edit: Jetzt wo Taks Posting da ist:
Dann macht das bitte so.

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

Ich hab nichts dagegen gesagt einen Wrapper oder ähnliches zu benutzen, der Context - nicht das Canvas - als solches sollte aber immer vom Programm selbst verwaltet werden. Es spricht nichts dagegen den Context zum zeichnen der GUI "auszuleihen".

Ich glaub hier wird Canvas und Context massiv durcheinander gebracht...

_________________
(\__/)
(='.'=)
(")_(")

Evil-Devil schrieb:

Wird es ja. Das Programm hat ja die (mittelbare) Verwaltung, indem es ein Fenster anfordert. Die Canvas hängt am Fenster, nicht an der GUI. Ich verstehe nicht, warum das so einen Aufschrei gibt.

I0n0s schrieb:

Ist das so? Wir haben uns an die Vorgaben gehalten, die abgesegnet worden sind. Bist Du jetzt wirklich dafür, das alles wieder umzuschmeissen, um nur ein ganz einfaches Ding aufzusetzen? Aktuell bekommt die GUI die Events über Wrapper und stellt sie dem Programm zur Verfügung. Du möchtest die Events selbst erhalten, ohne Umweg über die GUI? Ich möchte dazu eigentlich fragen, ob die anderen das auch so sehen.
Traude

Ich will mal ein aufruf zum Code recyeln machen und alle auffordern, ihren GUI code oder Codes die mit gui zu tun haben(font, texture,2d zeichen code) dem entwickler Team zur verfügung zu stellen.
Es wäre praktisch, code zu haben der bestimmte funktionen ermöglicht und diese mit anderen realisierungen zu vergleichen und eventuell, mit der erlaubnis der Entwickler , zu nutzten. Dies könnte den entwicklungsprozess verkürzen.
Ansprechpartner wäre dann ich, also einfach ne pm schicken und dann kann man weiter sehen.

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

Projekte: https://github.com/tak2004

Meine aktuellen Quellen kann ich euch nicht zur Verfügung stellen. Aber die würden euch eh nicht viel nützen, da es von den Komponenten her nicht sonderlich anspruchsvoll ist. Die Hauptarbeit liegt in der veränderten Struktur. Aber meine ältere Version steht nach wie vor auf meiner Webseite zur Verfügung. Diese ähnelt auch ein bisschen eurer Struktur.

Fonts gibt es die glText.pas von mir. Allerdings ist auch schon ein bisschen älter. Da arbeite ich aber auch an etwas anderem allerdings weiß ich nicht genau wann es fertig sein bzw wie es dann genau von der Klassenstruktur aussehen wird. Bzw wird das auch nur auf SDL aufsetzen. Also keine Ahnung ob es was nützen würde. Quellen gibt es wie gesagt noch nicht.

Hallo,
Ich habe die letzten paar Tage mit Code umschreiben verbracht und bin damit noch einige Zeit nicht fertig. Beim Stöbern im Free-Pascal-Source-Code ist mir aufgefallen, dass in der FCL (Free Component Library, Unterverzeichnis "\Source_fpcbuild_2.0.4_exp\fpcsrc\fcl") ein Verzeichnis "Image" enthalten ist, das offenbar bmp, jpg, png und tga einlesen und auch schreiben kann. Hat schon jemand Erfahrungen damit gemacht?
Traude



@Edit: Ich hab es mir ein wenig angesehen. Es kann offenbar nicht nur Bilddaten einlesen/ausgeben, es hat auch eine Anbindung an FreeType drin. Es gibt dazu keine Dokumentation, das einzige, was ich gefunden habe war: http://community.freepascal.org:10000/lists/fpc-pascal/2004-April/006907

Als Erklärung: ich interessiere mich für Alternativen zu SDL, weil SDL für das Einrichten des Rendering Context wegen des fehlenden multi-Windows-Supports nicht mehr in Frage kommt. Und da mache ich mir Gedanken, ob man für die Textur und die Schrift bei SDL bleiben soll - die greifen ja auch nur auf die Bibliotheken für jpeg und png zu. Wenn man mit nativem Pascal-Code aus FPC direkt auf diese Libraries zugreifen kann, würde das eine Abhängigkeit weniger sein. Was meint Ihr dazu?

Weiters habe ich auf der Free Pascal Website eine weitere GUI für Free Pascal gefunden, die ich noch nicht kannte, Beschreibung siehe http://www.freepascal.org/wiki/index.php/MSEide_&_MSEgui.

Hallo, ihr VCL-Spezialisten
ich hätte heute eine ganz dumme Frage an Euch.

Mir ist heute Folgendes bewusst geworden (ich wusste das eigentlich schon vorher, aber nicht in dieser Deutlichkeit):

Unser GUI-Baum wird - im aktuellen Konzept - über TObjectlist realisiert: ein Knoten hat eine Liste, in der Knoten sitzen, von denen wieder jeder eine Liste hat....). Die VCL erzeugt ihren Baum im Gegensatz dazu über die Schachtelung von Komponenten: TPanel wird zum Beispiel mittels automatisch generiertem Pascal-Code als published property des TForm erzeugt, wenn man es aufs TForm zieht.

Überhaupt werden ALLE Controls als published property des TForm erzeugt: wenn ich jetzt einen TButton auf das Panel setze, ist dieser Button KEIN property des TPanel, sondern des TForm. Das ist kein echter Objekt-Baum, sondern eine LISTE von Objekten. Eine Schachtelung (also einen Baum) kann ich erreichen, wenn ich TFrame benutze.




DIE DUMME FRAGE LAUTET: sehe ich das richtig? Und wenn ich das richtig sehe, welche Vor- und Nachteile hat der Baum, der seine Knoten nicht als published properties, sondern als Objekte einer Liste implementiert? Einen echten Baum kann man sowohl mit der einen als auch mit der anderen Variante realisieren.

Einen Vorteil des Listen-Baums kann ich Euch erzählen, weil ich das Zeug grossteils schon geschrieben habe: Wenn ich sicher sein kann, dass das TPanel die TButtons, die auf ihm drauf sind, auch besitzt, habe ich es leichter beim Mausklick: ich brauche nicht mehr alle Elemente abzufragen, ob sie angeklickt worden sind, sondern wenn ich feststelle, dass das Panel angeklickt worden ist, brauche ich nur mehr seine Children zu fragen. Vermutlich ist das aber bei der Schnelligkeit der heutigen Computer kein Vorteil, der wirklich ins Gewicht fällt.

Vielleicht ist das auch gar kein wirklicher Vorteil: es lässt sich in der VCL der Button, der auf ein Panel gesetzt wurde, nicht mehr aufs Formular verschieben (weil das Panel einen eigenen Device Context hat und somit ein eigenes Fenster ist???), also berücksichtigt die VCL offenbar, dass der Button zum Panel gehört. Der Listenbaum spiegelt in seiner Struktur dagegen das wider, was auf dem Bildschirm zu sehen ist: ein Button wäre ein Child des Panel.

Ein Nachteil des published-property-Baums ist es wohl, dass ein EIGENES Formular abzuleiten ist, damit er alle die published-property-Controls unterbringen kann. Der Listenbaum hat dagegen die natürliche Fähigkeit, leichter erweiterbar zu sein: die Liste kriegt eben einfach ein neues Objekt dazu und solange es aus dem Basis-Widget abgeleitet ist, können die Widgets miteinander kommunizieren. Das WindowWidget muss dazu nicht neu abgeleitet werden.

Fallen Euch noch Aspekte dazu ein?

Traude

Die Elemente auf einem VCL-Form werden als Variable in das Form geschrieben, weil a) man im Code der Form dann besser auf die Elemente zugreifen kann und b) man anderenfalls für jedes Panel eine eigene Klasse generieren müsste, um z.B.: mit Panel1.Button1 darauf zuzugreifen. Weiterhin sind diese Variablen published, damit sie über das eingebaute streaming-System aus der DFM mit ihren Eigenschaften versorgt werden können.
Auch VCL hat eine Baumstruktur, nämlich die Parents, um zu wissen, welches HWND auf welchem HWND liegt und somit wie geclippt werden muss. Dass der Owner jeder Komponente, egal wo sie liegt die Form ist, liegt wiederum an der Tatsache, dass sie eben alle Variablen der Form sind.
Bei Frames ist das, wie Du schon sagtest eine andere Sache, da die Frames ja eigene klassen sind mit eigenen Variablen. Hier ist nur der Frame ein Member der Form und alle Komponenten auf dem Frame Member des Frames. Auch hat ein Frame eine eigene dfm und liest seine Komponenten selber aus.

Ich sehe da nicht unbedingt Vorteile, ausser den direkten Zugriff auf die einzelnen 'Subkomponenten' über ihren Variablennamen. Es ist einfach eine andere Herangehensweise. Auch ist es uns nicht möglich einfach neue Variablen und Properties zur Laufzeit zu deklarieren. Von daher finde ich den Ansatz mit dem Baum wesentlich sinvoller.

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.

Danke für die Antwort.

Verflixt! Ich verwechsle das mit dem Owner und dem Parent immer, weil das bei mir gleich ist . Du hattest es mir schon einmal gesagt.

Sidorion schrieb:


Als Erklärung: ich bin auf diese Frage gekommen, weil ich grade an einem vergleichbaren "Daten-Versorgungssystem" arbeite, und dabei in der VCL herumstochere, um zu sehen wie es dort gemacht wird.

Sidorion schrieb:

Das habe ich derzeit nicht, sehe ich aber ganz locker: weil ich noch im Anfangsstadium bin, muss ich meine Elemente mit



selbst erzeugen und habe dadurch gleich einen Zeiger drauf. Denkbar wäre auch eine Suchfunktion



Da gibts bestimmt genug Möglichkeiten, dem Programmierer eine Variable zukommen zu lassen.

Vergesst bitte nicht, dass die VCL auch nur zu großen Teilen die Windows API benutzt. Panel, Forms, Buttons, Edit sind in Wirklichkeit alles nur Handles von Fenstern im inneren von Windows. Die VCL kappselt das alles nur und verarbeitet die Meldungen die vom Windows kommen. Klar so Komponenten wie Labels, Paintboxen darum kümmert sich die VCL von alleine. Aber einen Text irgendwo auf ein DC zu zeichnen ist wohl nicht so kompliziert. Und würde als extra echtes Fenster wohl eher nur Nachteile anstelle von Vorteilen bringen.

Aber wie gesagt. Die wirkliche Baumstruktur liegt im inneren von Windows. Folgendes Beispiel



Mit folgendem WindowsAPI Aufruf wandert augenblicklich das Panel2 auf das Formular. Gut zu erkennen an der entsprechenden Positionsänderung in Abhängiggkeit des Panel1. Oder mit dem Winspector der direkt die Baumstruktur aus dem Windows ausließt bzw Flags etc setzen kann.