Imho gibt es in FreePascal nen Compilerschalter für den Delphi-Modus. Wenn Du den am Anfang der Unit setzt, wird die Unit grundsätzlich im Delphi-Modus übersetzt, auch wenn das restliche Programm nicht in dem Modus arbeitet.

_________________
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.

Ja stimmt schon. Aber ich arbeite eigentlich in Delphi, weil ich mich mit dem FPC-Debugger noch nicht angefreundet habe, und gehe mit dem ganzen Zeug von Zeit zu Zeit ins FPC, um zu sehen, ob es dort auch kompilierbar ist (grade beim RTTI war das nicht immer der Fall). Und Delphi meckert über die Compiler-Direktive "Mode Delphi" und ich bin zu faul, um sie jedesmal rauszunehmen und wieder reinzuschreiben. Ich habe die Direktive in meiner FPC-IDE eingestellt.

Auszug aus dglOpenGL.pas:

So kannst Dus für beide übersetzen.

_________________
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.

OK, Danke. In diesen Belangen habe ich noch viel dazuzulernen.

Kleiner Zwischenbericht:
Ich habe meinen letzten Angstgegner in den Griff bekommen: gestern habe ich eine Basisversion von Themes einrichten können. Ich kann der GUI per Textdatei jetzt sagen, wie sie auszusehen hat (derzeit: Farben/Zeichenprozeduren/Schriften/Texturen). Ich dachte eigentlich, das ist ein Musskriterium. Jetzt habe ich im Wiki-Pflichtenheft nachgesehen und da steht es als Wunschkriterium drin. Hab ich vergessen (dabei habe ich das Pflichtenheft selber geschrieben, ist nur schon lange her ........)

Da sieht man mal wieder, wie schnell manche Wünsche in Erfüllung gehen

_________________
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.

Heute möchte ich Euch eine Frage stellen. In meinen Vorgaben zur GUI steht:
"Das Standard-Aussehen des GUI folgt dem Betriebssystem Windows."

Dabei bin ich jetzt gerade. Ich habe natürlich schon ein paar Test-Controls gemacht, aber jetzt betreibe ich Grundlagenforschung. Und muss erstaunt feststellen, dass Knopf nicht gleich Knopf ist (z.B. hat Windows 2000 einen anderen "Look" als XP; Windows Vista habe ich nicht aber ich habs mir angesehen. Ich bin einem Link aus der Wikipedia gefolgt und Vista hat - per FireFox! - meine CPU-Leistung auf 100% getrieben. Damit hat es mich ziemlich abgeschreckt. Ich muss aber zugeben, dass es gut aussieht).

Meine eigentliche Frage lautet aber: könntet Ihr mir bestätigen, dass Ihr WIRKLICH Windows-Controls haben wollt? Es handelt sich um eine GUI, die auch für Spiele geeignet sein soll. Wenn mir keiner antwortet, kriegt Ihr XP-Controls. Allerdings mit der Ausnahme der Fenster: Ich weigere mich entschieden, für Spiele den blauen Lutschbonbon-Balken zu implementieren.
Traude


NACHTRAG: ich hab mir diesen Beitrag nochmal durchgelesen: klingt echt unfreundlich. So ist es nicht gemeint. Ich meine: würdet ihr wirklich gerne XP-Controls haben? Bin für jede Antwort dankbar.

Das ist eigentlich egal. Die Controls sollten zum Design des jeweiligen Spiels passen. Da wird wohl jeder sowieso einen eigenes Theme erstellen müssen.

OK. Das bedeutet für mich: Ich halte mich so neutral wie möglich. Und ich werde ein neues Hobby entwickeln: ich sammle Zeichenprozeduren. Derzeit habe ich:

Rechtechte
RoundRects
Ellipsen (sehr variabel, schließen auch Vielecke mit ein)
(Dreiecke fehlen mir, fällt mir grade auf. )

zu jeder dieser Formen gibt es passende schattierte Rahmen und Textur.

Wenn jemand eine neue Idee dazu hat: immer her damit.

Wenn mit "Das Standard-Aussehen des GUI folgt dem Betriebssystem Windows." der Fallback gemeint ist, dann kanns auch ne simple Bummi-3D-Oberfläche ala win95 sein.
Hauptsache man kann ein Edit-Feld von einem Button unterscheiden. Das Aussehen sollte soweso jeder für seine Bedürfnisse anpassen.

_________________
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.

Verflixt ich habe schon wieder vergessen, dass ich Euch gar kein Fenster abliefern soll. Ihr wollt die GUI ja selbst verwalten, und das Fenster/ den Rendering Context auch selbst verwalten. Ich habe für meine EIGENE Anwendung schon ein Fenster als GUI-Verwalter, und da habe ich das Problem mit dem XP-Balken. Aber OK, das ist nicht Euer Problem, sondern nur meins sorry.

Aber das bringt mich auf noch ein Problem, nämlich das Schnittstellen-Problem, ich meine die Schnittstellen zwischen der GUI und dem Anwendungsprogramm.

Die erste Schnittstelle ist das GUI-Root, der den GUI-Baum verwaltet und die Events entgegennimmt. Das ist aber kein Problem, jedes GUI-BasisWidget könnte den Baum verwalten, und Ihr könnt den Verwalter auch so ausgestalten, wie Ihr wollt. Ich brauch Euch dafür gar nichts Zusätzliches zu liefern, das Basis-Widget gibt es ja schon.

Weitere Schnittstellen sind aber die Zeichenprozeduren/Schriften/Farben/Texturen. Und hier müssten wir eine Einigung erzielen, denn die GUI sagt nur: jetzt bitte ein Zeichendingsbums einschalten. Aber die Frage ist, WIE sie das sagen soll.

Ich habe ein GraphicTool, das meine Schnittstelle zwischen der GUI und dem Anwendungsprogramm ist, denn es verwaltet alles, was ein Zeichenprogramm so braucht. Wohlgemerkt: das GraphicTool ist kein Bestandteil der GUI, sondern eine Schnittstelle. Was ich jedenfalls brauche, ist die Möglichkeit, auf Zeichenprozeduren/Schriften/Farben/Texturen mittels Namen (Themes!) Zugriff zu erhalten (der Knopf muss sagen können: Gib mir die Zeichenprozedur namens "ShadedBox"). Und über diese Schnittstelle muss Klarheit herrschen.

Ich beschränke mich jetzt aufs absolute Minimum:

1) Zeichenprozedur: prozedurale Variable (oder Methode), bitte nicht beides
2) Schrift: das muss ein Objekt sein, mindestens mit den Methoden "TextOut", "TextWidth", "TextHeight", vielleicht braucht es aber noch mehr, weiß ich noch nicht
3) Textur: es genügt ein Cardinal, wenn man OpenGl als Maßstab nimmt
4) Farbe: ein Objekt, weil:

Bei der Farbe hatte ich Schwierigkeiten, obwohl das von Ferne ganz einfach aussieht. Und zwar deshalb, weil die Zeichenprozeduren genormt sein müssen. Der Knopf sagt ja nicht: "Zeichne eine shaded Box", sondern der Knopf sagt: "Zeichne meine Zeichenprozedur", weil die Zeichenprozedur wechselbar sein muss und daher eine prozedurale Variable ist. Die genormte Zeichenprozedur übernimmt nur eine wohldefinierte Menge von Parametern, und die Vordergrund-Farbe ist auch ein Parameter. Daher habe ich hier ein Farb-Objekt, das von seiner Farbe Abstufungen erzeugen kann, das erweitert die Möglichkeit der Farbe enorm: ich kann damit z.B. räumlich wirkende Dinge zeichnen und brauch nur einen Parameter (das Farbobjekt) übergeben.

---------------------------------------------------------------------------------------------------------------------

Dann habe ich noch eine Anmerkung:
Im Wiki-Pflichtenheft steht Folgendes drin:

Punkt: Produktfunktionen/UserProzesse/Benutzereingaben:


Eine solche Vorgabe kann ich nicht erfüllen, wenn die Aufgabe der GUI auf das visuelle Anzeigen von Widgets beschränkt ist, wenn also das Abholen von Betriebssystem-Ereignissen nicht von der GUI erledigt werden soll, sondern das Anwendungsprogramm macht das selbst, wie Ihr mir früher in diesem Thread klargemacht habt.

Diese Idee mit dem Tastaturschema stammt nicht von mir, aber damals erschien es mir irgendwie logisch, dass die GUI nicht nur zeichnet, sondern auch die Benutzerereignisse abholt, und daher hab ich das auch selber so hineingeschrieben.

Konsequenterweise muss dieser Punkt (und ähnliche Punkte) jetzt gestrichen werden.
Traude
-------------------------------------------------------------------------------------------------------------------------------------------

Edit: Ich sagte oben: der Knopf muss sagen können: Gib mir die Zeichenprozedur namens "ShadedBox". Aber das genügt nicht. Die GUI muss auch sagen können: Lade eine Textur namens "Gänseblümchen").

Zu dem "Windowslook":
Wie sidoran schon gesagt hat:
Die Komponenten sollten alle mit dem Aussehen von Windows 9x/ME/2000 bzw. dem Classiclook aussehen. Dies ist aber nur der Fallback-/Defaultmodus.
Über die Themes sollte es dann möglich sein das Aussehen anzupassen und wenn jemand BonbonXP will darf er sein eigenes Theme schreiben

Zu dem Schnittstellenproblem:
Könntest du das für mich noch mal kürzer bzw. prägnanter zusammenfassen. Ich kann da nicht klar sehen worauf du hinaus willst.

Zu der Tastaturgeschichte:
Das kannst/solltest du so nicht implementieren, vielleicht ist es ja auch von einem User gewollt? Aber wenn es möglich wäre, wäre eine eigene Funktion zum "Ummappen" der Tasten hilfreich. Ich weiss aber nicht inwiefern das schon implimentiert ist bzw. implimentierbar ist.

Gruss
Jonas

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

Jonas schrieb:


Eine der Funktionen des GUI ist das Zeichnen, aber es soll das nicht selbst tun, sondern nur "in Auftrag" geben, weil es auch Graphic-Library-unabhängig sein soll. Daher steht das GUI vor dem Problem, dass es keine Mittel zum Zeichnen hat. Die Mittel zum Zeichnen (Zeichenprozeduren/Farben/Schriften/Texturen) werden vom Anwendungsprogramm zu Verfügung gestellt. Das bezeichne ich als "Schnittstellen", denn es sind Berührungspunkte mit dem Anwendungsprogramm, das ja auch vor dem Problem steht, Zeichenmittel zu brauchen.

Die Funktionstrennung finde ich auch deswegen sinnvoll, weil die Graphic-Library damit unabhängig genug von der GUI ist, um optimieren zu können: ich habe zwar eine Ellipsen-Zeichenmethode, aber vielleicht hat ja einer eine schnellere, bessere Zeichenmethode. Wenn man das verbessern möchte, muss man nicht in der GUI herumrühren.

Konkret sieht das bei mir so aus: Ich brauche ein Allround-Objekt (das Graphic-Library-ABHÄNGIG ist), das mir die Zeichenmittel zur Verfügung stellt (Du kannst es TCanvas nennen oder TGraphTool oder irgendwie so). Diesem GraphTool muss der TMyButton sagen können:

1) Gib mir ein Bild namens "OpenFile"
2) Gib mir eine Farbe "Hellblau"
3) Gib mir eine Zeichenprozedur "Ellipse"
4) Gib mir eine Schrift "Arial"
5) Gib mir was auch immer

Mein Pascal Quelltext dazu lautet derzeit:


Wie das GraphTool das macht, bleibt ihm überlassen. Ich muss das TGraphTool natürlich schon implementieren, drum hab ich für meine Testanwendung so lange gebraucht, aber strenggenommen ist das GraphTool kein Bestandteil des GUI. Die Variablen Texture, ForegroundColor etc. sind Properties des Standard-Controls, die es seiner Zeichenprozedur mitgeben kann.

Jonas schrieb:

Ich habe in meiner Testanwendung eine Implementierung (ist auf Taks Server und auch oben in meinem Beitrag) drin, ging ja gar nicht anders. Windows liefert die virtuellen Tastencodes und die ASCII-Codes der alphanumerischen Tasten, die sollten eigentlich unabhängig vom Tatstaturschema sein (glaub ich).

Traude

Ok, jetzt verstehe ich worauf du hinaus willst.

Die Frage ist ob man OpenGL so performant kabseln kann.
Wenn nicht sollte man überlegen was man will. Ich will eine OpenGL-Gui. Wenn es möglich ist, darf gerne es auch gerne über WinAPI gehen, aber OpenGL ist die Priorität, und zumindest das mit der Farbe sowie der Ellipse sollte schonmal Default über OpenGL implimentiert sein.
Für mich ist einfach die Frage ob so eine Trennung es verhindert die GUI bzgl. Geschwindigkeit unter OpenGL zu optimieren.

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

Im Gegenteil, was ich von meiner Testanwendung gesehen habe, erleichtert die Trennung das Optimieren, weil sich jeder von beiden als "Spezialist" auf sein ureigenstes Gebiet konzentrieren kann.