Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Fr Mär 29, 2024 05:53

Foren-Übersicht » Sonstiges » Community-Projekte
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 427 Beiträge ]  Gehe zu Seite Vorherige  1 ... 25, 26, 27, 28, 29  Nächste
Autor Nachricht
 Betreff des Beitrags:
BeitragVerfasst: Di Apr 03, 2007 11:00 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Könnte man machen, man kann auch ein interpreter ran hängen, der aus der themefile seine zeichenfunktion bekommt. So hat es GTK Theme gemacht.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Apr 03, 2007 13:16 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Gut gekontert, würd ich sagen. :wink:

Aber bei mir kommt die Zeichenfunktion auch aus dem Theme - ich brauch dafür gar keinen Interpreter. Der Renderer macht's möglich: in der Theme-Datei steht: "TBUTTON -> Zeichenprozedur = Ellipse" (einfach als Text).

Die Widgets stellen sich (in einer kurzen Methode "GetGraphicTools", die im Konstruktor aufgerufen wird) bei ihrem Root an, sagen ihre Klasse, kriegen den richtigen RendererNamen übergeben, kriegen mit diesem Namen beim GraphTool das Renderer-Objekt und installieren sich diesen Renderer einfach selbst.

Sollte der Text in der Theme-Datei falsch gewesen sein (dh. es gibt keinen solchen Renderer), muss das Widget eben den Default-Renderer nehmen.



EDIT: Jetzt war ich neugierig und habe nachgesehen: http://developer.gnome.org/arch/gtk/themes.html

Sie brauchen das Ganze, um auch die Renderer von aussen erweitern zu können. Klar, Zeichnungen gibt es unendlich viele, und ich kann im compilierten Programm nur eine begrenzte Anzahl davon haben. Eigentlich habe ich das immer so gesehen, dass nicht das Programm ausgeliefert wird, sondern nur die GUI als SourceCode. Dann wäre es kein Problem, man schreibt einfach einen neuen Renderer.

Aber wenn man dem Renderer eine Punkteliste liefert (ich meine jetzt zusätzlich zu den normalen Zeichenroutinen, möglicherweise als "Plugin"), dann könnte man das Problem vielleicht in den Griff kriegen? Ich muss mal drüber nachdenken.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Apr 04, 2007 07:59 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Ich habe gestern Abend ein neues Konzept für den Renderer ausgearbeitet: ich habe dem Widget eine Triangle-Liste verpasst; das Problem mit dem Widget-Frame hatte ich zunächst auf die lange Bank geschoben. Und ich hatte auch schon begonnen, Code umzuschreiben (es ist fast so schlimm, wie ein Gebäude abzureißen. :( Gottseidank sind die "Abbrucharbeiten" wegen des OOP auf den Renderer beschränkt). Allerdings sind diese Änderungen tiefgreifend, und ich wurde damit selbstverständlich nicht fertig.

Morgens sieht immer alles ganz anders aus. Kennt Ihr das? Irgendwie war mein Alter Ego mit dem Konzept nicht zufrieden. Wenn das passiert, mach ich Folgendes: einen Schritt zurückgehen (bildlich gesprochen) und versuchen, etwas unter einem allgemeineren Aspekt neu zu definieren.

Was ist die Definition so eines Renderers? Anders gefragt: was ist das WESEN eines Renderers? Noch anders gefragt: gibt es eine Art "Quintessenz" eines Renderers?

Der Schluss, zu dem ich gekommen bin, lautet: :idea: Das Wesen eines Renderers (wir befinden uns in 2D) ist die 2D-SILHOUETTE einer Form. Diese Silhouette kann man mit einer Punkteliste definieren. Dreiecke gehören zunächst mal nicht dazu.

Was kann ich jetzt mit dieser Erkenntnis machen? Nur zur Erinnerung: wir haben nur EINEN Ellipsen-Renderer aber viele Widgets mit ihren "viereckigen Plätzchen", die Anspruch auf einen Ellipsen-Renderer haben. UND wir haben OPENGL. Der Renderer kann seine ALLGEMEINE Ellipsen-Silhouette z.B. in eine Displayliste stecken. Und das bedeutet: wir können unser User Interface HARDWARE-BESCHLEUNIGEN. (@Jonas: was sagst Du jetzt, hm? ALLEIN für diese Erkenntnis rechnen sich 28 Seiten Thread, denn das ist Brainstorming - von der allerfeinsten Sorte: die Idee mit der allgemeinen Form hatte ich irgendwann mal früher, aber die Idee mit dem Renderer stammt von Lars).

Was die Dreiecke betrifft: Die Silhouette kann anlässlich des Renderer-Create automatisch trianguliert werden.

Was die Erweiterbarkeit der Anzahl der Renderer betrifft: Wenn das Programm per Datei eine Silhouette einliest, kann sie damit eine neue Renderer-Instanz erzeugen. Auf diese Weise lässt sich praktisch JEDE Form erzeugen (Herzchens zum Beispiel, örps :twisted: ). Schriften und Texturen müssen schliesslich auch eingelesen werden.

Ich werde auf jeden Fall versuchen, das Widget "punktelistenfrei" zu halten. Möglicherweise kann man den verbesserten Hit-Test mit der allgemeinen Dreiecksliste des Renderers und einer Skalierung machen, aber genau weiß ich es noch nicht.



EDIT: fürs Triangulieren von Formen mit Löchern muss ich allerdings meine Triangulierungsroutine erweitern.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Apr 18, 2007 09:41 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Ich habe heute einen kleinen ZWISCHENBERICHT (Fragen poste ich hier nicht mehr, da sie bereits so speziell sind, dass man das auch im normalen Forum machen kann):

Ich bin beim Programmieren der Widgets. Fertig sind bisher:

------ Button, CheckBox, Image, Label, Panel, ProgressBar, ScrollBar(Horizontal+Vertical).

Diese Items sind in der Unit GUIDescendants zu finden. Da sind zwar noch ein paar mehr drin, aber die sind entweder nur zu Hilfszwecken gemacht oder noch nicht fertig.

Die ListBox habe ich grade in Arbeit. Daher kommt sie auch in meiner Testanwendung hoch, wenn man das Programm startet. Sie funktioniert zwar schon teilweise, ist aber noch totale Baustelle.

Wie immer habe ich den SourceCode wieder in diesen Thread gestellt (auf Seite 24, ganz unten),
und auch auf Taks SVN hochgeladen (ich habe in der Zwischenzeit ein paar interessante Objekte in der Unit GraphicSupport hinzugefügt).

Von den kleineren Widgets fehlen mir (lt. Vorgabe im Wiki Pflichtenheft):
RadioBox***), EditBox, ListBox (in Arbeit), ComboBox

Wenn ich mit den kleineren Widgets fertig bin möchte ich eine neue Testanwendung schreiben, wo man die einzelnen Widgets demonstrieren bzw. auch besser Fehler finden kann. Auch werde ich dann anfangen, eine Beschreibung zu erstellen, denn die Grundstrukturen haben sich bewährt, das heißt der Programmunterbau dürfte in Ordnung sein.

Da dieser Thread hier zu groß und unübersichtlich ist, werde ich mich irgendwie umorganisieren müssen.




***) Ich habe vergessen, was eigentlich mit 'RadioBox' gemeint ist: eine GroupBox oder ein RadioButton oder beides?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Apr 18, 2007 11:05 
Offline
DGL Member

Registriert: Mo Dez 20, 2004 08:58
Beiträge: 442
Wohnort: Mittweida (Sachsen)
Ich nehm mal an, eine RadioGroup ist gemeint, schaden kanns aber nicht, wenn alle drei vorhanden sind.

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Apr 18, 2007 11:21 
Offline
Ernährungsberater
Benutzeravatar

Registriert: Sa Jan 01, 2005 17:11
Beiträge: 2067
Programmiersprache: C++
Ich hatte mal Tak gefragt wie es mit den Wrappern aussieht. Er meinte, dass es da noch nichts festes gibt.
Ich weiss zwar nicht wie der aktuelle Stand ist, aber diese Aussage hat mich sehr gestört.

Diese Schnittstelle sollte eigentlich jetzt schon zum Grossteil fest stehen. Diese Schnittstelle ist ein Fundamentteil der GUI und sollte vor den Widgets Prioritäten haben und zumindest die Schnittstellen für Font und Texturen sollten fest stehen, die für "Formen" sollte in groben Zügen auch schon fest stehen (Hier sollte sich aufgrund von runden GUI-Elementen vermutlich noch am meisten bewegen).

Wie ist den da jetzt der aktuelle Stand und falls es schon fest ist, in welchem Ordner des SVNs kann ich den Wrapper finden, damit man ihn dokumentieren sowie für easySDL adaptieren kann?

_________________
Steppity,steppity,step,step,step! :twisted:
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ❄ ❆ ❄ ❄


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Apr 18, 2007 12:26 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Aktuell gibt es ja ein miniglaubenskrieg zwischen Texturbasierten Widgets und Poligonbasierten Widgets.
Ich vertrete die Polygonbassierten Widgets, mit ZeichenStacks und Traude eher das nutzen von Texturen.
Ausserdem hab ich aufgrund meiner Belege keine Zeit aktuell dran zu arbeiten und so macht Traude aktuell alles allein.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Apr 18, 2007 13:55 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Ich hab von einem Glaubenskrieg nix mitbekommen. Ich mach das derzeit so, dass ich Taks Vorschlag betreffend die Polygone übernommen habe. Ich hab aber nur die Struktur vorbereitet, noch nichts implementiert. Das ist aber kein Problem: den benötigten Programm-Code habe ich, muss ihn nur reinkopieren und natürlich ein bisschen anpassen. Da muss man vorher aber fragen was denn das "Polygon-Mesh" für eine Datenstruktur haben soll (bitte eine möglichst einfache). Ich hatte eigentlich vor, die Texturen auf die Widget-Silhouette zu spannen und wollte die Dreiecke nur für den Hittest verwenden.




@I0n0s: Ja, das ist wichtig. Die Schnittstellen hatte ich oben schon mal thematisiert, aber das ist eigentlich offen geblieben.

Es ist m.E. klar, dass der GUI-Baum selbst ins Programm eingebunden werden muss und NICHT Bestandteil einer DLL sein kann. Der Baum erfüllt für das Programm zwei Funktionen:

1) Man kann mit seiner Hilfe Programm-Module miteinander verbinden (das ist seine Leitungs- oder Relaisstationsfunktion; mein Programm könnte ja auch nur aus dem Baum bestehen und die echte Funktionalität hole ich mir aus den DLLs; was ich damit meine: den Baum brauch ich auf jeden Fall, es sei denn, man will ein Konsolen-Batchprogramm ablaufen lassen)

2) Man hat die Möglichkeiten, diesen Leitungen und Schaltern zusätzliche Funktionen zu geben. In dem Fall sind es "Innenarchitekten", die zwar vorgeben, was wie auf dem Bildschirm erscheinen muß, aber das nicht selbst tun. Wir nennen das ganze Gebilde dann GUI. Vielleicht könnte man auch die "Innenarchitekten" in eine DLL packen. Aber das Zeug ist so miteinander verquickt, dass ich mir ein wenig schwer tu, mir das vorzustellen. Man müsste versuchen, die Leitungen von den "Innenarchitekten" zu trennen. Lustigerweise hab ich das sogar einmal gemacht: ich habe das TGUIItem getrennt in ein TGUISwitch (das ist der mit den Leitungen) und ein TGUIShape (das ist der Innenarchitekt, der die Daten fürs Zeichnen kommandieren kann). Ich habe es aber wieder zusammensetzen müssen - was ich sehr bedauert habe - ich erinnere mich nicht mehr wirklich an den Grund aber es hatte etwas mit der Vererbung zu tun.

Das Zeichnen macht die Grafiklibrary, also OpenGL.

Was ich über diese Schnittstelle kriegen muss, hat sich in Wirklichkeit nicht geändert. Wenn ich jetzt mal den kleinsten gemeinsamen Nenner aufzählen darf:

1) Farben: eine RGBA-Farbe macht geringe Probleme, es handelt sich um einen 32-Bit Integer
2) Texturen: OpenGL-Texturen brauchen nur ein "Handle", ein Cardinal
3) Schriften: Meine Schrift ist in Displaylisten gepackt, und zwar genauso, wie Du das bei EasySDL gemacht hast. Kann wieder mit einem Cardinal angesprochen werden.
4) Renderer: das hat sich jetzt total vereinfacht. Ich habe die Dinger in DisplayListen gepackt, und die kann man ja auch über ein Cardinal aufrufen.
5) Was den obigen Hittest betrifft: das TriangleMesh sollte sich in der Grafik-Library befinden, die GrafikLibrary könnte damit auch am meisten anfangen. Ich verwende das Mesh derzeit nicht, aber das heißt ja nicht, das sich das in Zukunft nicht ändern kann. Der Hittest muss demgemäß auch in der GrafikLibrary stattfinden.

Rein theoretisch ginge das: Das Widget stellt bei seinem einfachen Bounding-Box-Test fest, dass es WAHRSCHEINLICH getroffen wurde. In diesem Fall ruft es die DLL-Triangle-Hittest-Funktion auf und übergibt ihr Folgendes: die Bounding Box (also Left/Top/Width/Height), die Mauskoordinaten, und die Nummer des Renderers. Der Renderer ist imstande, mittels der Bounding Box die Mauskoordinaten runter zu skalieren***) (weil auch das Dreieicksnetz und die Silhouette in der Dimension [1,1] vorliegt) und kann damit sagen, ob ein echter Treffer vorliegt.

Man kann ja schließlich auch Pointer, hinter denen eine komplexe Datenstruktur steht, aus einer Library kriegen. Aus meiner Sicht der Dinge müsste das mit der DLL grundsätzlich machbar sein. Die Prozeduren, die sich aufs Operating System beziehen, sind ohnehin so aufgebaut, das man sie leicht in eine DLL packen kann.

Man müsste den Grundsatz des OOP dann aber einschränken.


***) BoundingBox skalieren auf ein Quadrat mit der Länge 1; dieselbe Skalierungsfunktion auf die Mauskoordinaten anwenden. Eigentlich ist die Dimension [-0.5,+0.5] weil ich mir dann die Möglichkeit vorbehalten kann, das Zeug auch zu rotieren. :wink:

Und noch etwas: Mit dem Renderer kann ich jetzt jede Form erzeugen (auch ein zusammengeknülltes Plastiksackerl und zwar in jeder Größe), die Schnittstelle ändert sich dadurch nicht mehr.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Apr 18, 2007 14:52 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7804
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Kann es sein, dass der "Glaubenskrieg" die Diskussion hier im Forum war, was die Vorteile des Einen zum anderen sind? Dort wo Sascha geschrieben hatte, dass er Polybasiert arbeitet, und ich Texturbasiert? Ein Kireg war das nicht. Noch nicht mal ne Diskussion. Einfach ein Argumente aufschreiben. ;)

_________________
Blog: kevin-fleischer.de und fbaingermany.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Apr 18, 2007 15:24 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Könntest Du mir verraten, wo das ist? Ich finds nicht.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Apr 18, 2007 16:03 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
"glaubenskrieg" ist vieleicht zu hart ausgedrückt. Es war vielmehr ne Unterhaltung ohne Endresultat.
Ich bin der Meinung, das Polygonbasierte Systeme wesentlich praktischer für die allgemeine GUI ist.
Dies hab ich auch schon fertig implementiert aber noch nicht alle Widgets drauf umgestellt.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Apr 18, 2007 16:29 
Offline
Ernährungsberater
Benutzeravatar

Registriert: Sa Jan 01, 2005 17:11
Beiträge: 2067
Programmiersprache: C++
Traude hat geschrieben:
1) Farben: eine RGBA-Farbe macht geringe Probleme, es handelt sich um einen 32-Bit Integer
2) Texturen: OpenGL-Texturen brauchen nur ein "Handle", ein Cardinal
3) Schriften: Meine Schrift ist in Displaylisten gepackt, und zwar genauso, wie Du das bei EasySDL gemacht hast. Kann wieder mit einem Cardinal angesprochen werden.
4) Renderer: das hat sich jetzt total vereinfacht. Ich habe die Dinger in DisplayListen gepackt, und die kann man ja auch über ein Cardinal aufrufen.
5) Was den obigen Hittest betrifft: das TriangleMesh sollte sich in der Grafik-Library befinden, die GrafikLibrary könnte damit auch am meisten anfangen. Ich verwende das Mesh derzeit nicht, aber das heißt ja nicht, das sich das in Zukunft nicht ändern kann. Der Hittest muss demgemäß auch in der GrafikLibrary stattfinden.

Das die Theorie soweit steht ist mir klar, aber gibt es jetzt feststehende Wrapper die ich z.B. auf easySDL umschreiben?
Ich meine damit folgenden Code:
Traude hat geschrieben:
Mein Pascal Quelltext dazu lautet derzeit:
Code:
  1. Texture:= GraphTool.TextureByName['OpenFile'];
  2. ForeGroundColor:= GraphTool.ColorByName['hellblau'];
  3. DrawProc:= GraphTool.DrawProcByName['Ellipse'];
  4. Font:= GraphTool.FontByName['Arial'];

Gibt es somit schon eine wirklich feste Struktur von Graphtool die soweit fest steht und sich nur noch minimal bewegt?

_________________
Steppity,steppity,step,step,step! :twisted:
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ❄ ❆ ❄ ❄


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Apr 18, 2007 21:30 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Jetzt hab ich ein Problem. Ich habe ein GraphTool, das musste ich machen, für meine Testanwendung, aber das ist nicht akkordiert mit Thomas. Wenn wir jetzt etwas vereinbaren, dann muss er seinen Sanktus drauf geben oder, noch besser, bei der Vereinbarung dabei sein.

Aber ich kann Dir die Public Properties und Methoden hier mal reinstellen und wir können das diskutieren. Ich fürchte aber, das sich dieses Ding für eine DLL weniger eignen wird, Du wirst gleich sehen, warum. Ich mache massiven Gebrauch von den Vorteilen des OOP:

Code:
  1.    TGraphManager = Class(TCustomOwner)
  2.    Public
  3.       Property ColorByIndex[Index: Integer]: TRGBAColor
  4.          Read GetColorByIndex;
  5.       Property FontByIndex[Index: Integer]: TFreeType2Font
  6.          Read GetFontByIndex;
  7.       Property ImageByIndex[Index: Integer]: TRGBAImage
  8.          Read GetImageByIndex;
  9.       Property ShapeByIndex[Index: Integer]: TShape
  10.          Read GetShapeByIndex;
  11.       Property SymbolByIndex[Index: Integer]: TSymbol
  12.          Read GetSymbolByIndex;
  13.  
  14.       Property ColorByName[Index: String]: TRGBAColor
  15.          Read GetColorByName;
  16.       Property FontByName[Index: String]: TFreeType2Font
  17.          Read GetFontByName;
  18.       Property ImageByName[Index: String]: TRGBAImage
  19.          Read GetImageByName;
  20.       Property ShapeByName[Index: String]: TShape
  21.          Read GetShapeByName;
  22.       Property SymbolByName[Index: String]: TSymbol
  23.          Read GetSymbolByName;
  24.  
  25.       Constructor Create(AWindow: LongWord); Reintroduce;
  26.       Destructor Destroy; Override;
  27.       Procedure Initialize;
  28.        Function Register(AIDObject: TIDObject): Boolean; Override;
  29.       Procedure Resize(AWidth,AHeight: Integer);
  30.       Procedure PaintBegin;
  31.       Procedure PaintEnd;
  32.       Procedure SetLineWidth(ALineWidth: Integer);
  33.  
  34.    End;


Ich lasse mir damit die Objekte geben, die dann die wirkliche Funktionalität besitzen, OK, zugegeben, im Falle der Textur muss man dem Objekt alles, was gebraucht wird, schon im Create mitgeben. Verwendet wird dann eigentlich nur mehr die Texturnummer. Bei der Schrift ist das anders.

Man müßte für eine DLL die Standardfunktionen definieren, die man z.B.von einer Schrift haben will. Also so:

--- Mit welcher Schrift (ein Cardinal)
--- Mit welcher Farbe
--- Auf welcher Position
--- Und welchen Text

Bei Deiner EasySDL-Schrift heißt die entsprechende Methode z.B. Draw, glaub ich.

Ich komme also zu dem Schluß, dass eigentlich nicht mein Verwaltungsobjekt , sondern meine Objekte die Funtkionalität haben, die man als Schnittstelle definieren muss:

Das sind die öffentlichen Methoden und Properties meiner FreeType-Schrift. Die sind für die Schnittstelle geeigneter (das soll kein Vorschlag für die Schnittstelle sein, bloß zur Verdeutlichung dessen, was ich bisher gesagt habe).

Code:
  1. TFreeType2Font = Class(TIDOwnedObject)
  2.    Public
  3.       Property RGBAColor: RGBAColor Read fColor Write fColor;
  4.  
  5.       Constructor Create(AName: String;
  6.                         AOwner: TCustomOwner); Override;
  7.       Destructor Destroy; Override;
  8.       Function BuildFont: Boolean;
  9.       Procedure Show(XPos,YPos: Integer; AString: String);
  10.       //Procedure ShowSelect(XPos,YPos,SelStart,SelEnd: Integer;
  11.       //                AString: String);
  12.       Function TextHeight(AString: String): Word;
  13.       Function TextWidth(AString: String): LongWord;
  14.    Published
  15.       Property FileName: String Read fFileName Write fFileName;
  16.       Property Color: LongWord Read GetColor Write SetColor;
  17.       Property Size: Integer Read fSize Write SetSize;
  18.       Property Style: Integer Read fStyle Write fStyle;
  19.    End;
  20.  



Was jetzt die Schnittstelle genau betrifft: meiner Meinung nach sollst DU gar nichts anpassen, einfach deshalb, weil Du zuerst da warst. Viele verwenden das EasySDL schon. Im Gegenteil, wir müssen uns daher an DICH anpassen, weil Du damit schon einen Standard definiert hast. Thomas und ich haben mal gewitzelt: Was machen wir heute Abend, Brain....... Aber in diesem Fall warst Du der Erste mit der Weltherrschaft. :wink:

Ich könnte mir z.B. vorstellen, die ganze GUI auf EasySDL umzustellen (Texturen und Schriften), bei unseren Vorgaben muss das möglich sein. Und das wäre wünschenswert und auch sinvoll, oder? (Immer vorbehaltlich dessen, was Thomas noch dazu sagt). Ich tausche dabei die FreeType-Schrift gegen SDL_TTF und SDL_Image und habe dabei den Vorteil, auf einen Schlag mehr Bildformate handhaben zu können (derzeit habe ich nur BMP und TGA).

Was ich allerdings bitten würde: vielleicht wird es notwendig, bei der SDL-Schrift noch etwas zu ergänzen, z.B. das Ausgeben von (teilweise) invertiertem Text. Könntest Du das dann nachträglich einbauen?
Und ich nutze derzeit Schwarz als transparente Farbe. Weiß jetzt nicht, ob die EasySDL-Texturen das auch machen


@Thomas: DU bist dran.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Apr 19, 2007 11:08 
Offline
Ernährungsberater
Benutzeravatar

Registriert: Sa Jan 01, 2005 17:11
Beiträge: 2067
Programmiersprache: C++
1.: Zur DLL:
In diesem Topic wurde nie gefordert das die GUI als DLL funktioniert, die Idee entstand in nem gekaperten Topic und kann meiner Meinung nach erstmal begraben werden. Den wieviele Leute werden eine DLL nehmen und wieviele direkt linken? Nachdem Version 0.5 oder 1.0 draussen ist, k�nnen wir uns Gedanken machen wie wir das umsetzen, aber aktuell wird einfach zuviel auf die Wishliste getan, sodass die 'Wunsch'DGLGUI zwar eine eierlegende Wollmilchsau ist, aber aufgrund der Komplexit�t nie richtig zu laufen gebracht wird.

2.: Zum Wrapper:
TFreeType2Font trifft auf das zu was ich meine:
Es sollte eine TDGLGUIFont-Klasse geben, welche die f�r DGLGUI ben�tigten Funktionen enth�lt. DGLGUI liegt diese Unit mit TDGLGUIFont aber nur als Template vor, daher die Funktionen sind ohne Inhalt. Dann k�nnte z.B. Lossy seiner hoffentlich bald erscheinenden Fontunit einfach diese Unit mit 'gef�llten' Funktionen mitliefern, sodass man nur das Template ersetzen muss damit DGLGUI mit Lossy's Fontunit l�uft.

Graphtool ist schon zu �bergeordnet. Dies kann man nicht einfach ersetzen, einfach weil dort zuviele Komponenten zusammenkommen.

Daher:
Wie sieht es jetzt mit Dingen wie TFreeType2Font bei Font, Texture sowie Zeichnen aus?

Gruss
Jonas, dem gerade daheim das Internet ausgefallen ist -.-
Und der Umlautprobleme beim Transport des Textes zur Uni hatte...
Wobei das anscheinend eher Konquerer vs. Firefoxproblem ist.

_________________
Steppity,steppity,step,step,step! :twisted:
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ❄ ❆ ❄ ❄


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Apr 19, 2007 13:10 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
ZU DEINEM PUNKT 1: einverstanden.

ZU DEINEM PUNKT 2:
Zunächst brauche ich eine Verwaltung, und damit die ihren Dienst tun kann, müssen die verwalteten Objekte identifizierbar sein (ich nehme einen Namen) und die Verwaltung braucht eine Registrierung, welche die Objekte in eine Objekt-Liste steckt, wo man sie einfach finden kann.

Ich mache das so:
Code:
  1. //********************************************************************
  2.    TIDObject = Class(TPersistent)
  3.    Private
  4.       fName: String;
  5.       Procedure SetName(AName: String);
  6.    Public
  7.       Constructor Create(AName: String); Reintroduce;
  8.    Published
  9.       // Properties for loading/saving
  10.       Property Name: String Read fName Write SetName;
  11.    End;
  12. //********************************************************************
  13.    TCustomOwner = Class(TObject)
  14.    Public
  15.       Function Register(AIDObject: TIDObject): Boolean; Virtual; Abstract;
  16.    End;
  17. //********************************************************************
  18.    TIDOwnedObject = Class(TIDObject)
  19.    Private
  20.       fRegistered: Boolean;
  21.    Public
  22.       Property Registered: Boolean Read fRegistered;
  23.       Constructor Create(AName: String;
  24.                   AOwner: TCustomOwner); Reintroduce; Virtual;
  25.    End;


Wenn Du noch mal nach oben blätterst ist die FreeTypeFont ein TIDOwnedObject; ein etwas unglücklicher Name, der ausdrücken soll, dass es sich um ein Objekt mit einer Identität und einem Besitzer handelt. Das TIDObject ist wegen der RTTI-Funktionalität aus dem TPersistent abgeleitet (fürs Laden und Speichern von Widgets).

Mein GraphTool ist ein Verwalter und aus dem TCustomOwner abgeleitet. Es erzeugt zu Beginn ein paar unverzichtbare Objekte (das hab ich ein bisschen gekürzt, nur als Demo):

Code:
  1. Constructor TGraphManager.Create(AWindow: LongWord);
  2. Begin
  3.    Inherited Create;
  4.    fWindow:= AWindow;
  5.  
  6.    // Set up basic colors --------------------------------------------
  7.    fColors:= TObjectList.Create;
  8.    TRGBAColor.Create('SOLIDGREY',   Self, SOLIDGREY);
  9.  
  10.    // Set up basic font ----------------------------------------------
  11.    fFonts:= TObjectList.Create;
  12.    TFreeType2Font.Create('timr46w',Self);
  13.  
  14.    // Set up basic images --------------------------------------------
  15.    fImages:= TObjectList.Create;
  16.    TRGBAImage.Create('DummyImage',Self);
  17.    TRGBAImage.Create('FIGURES64X64',Self);
  18.  
  19.    // Set up ALL shapes ----------------------------------------------
  20.    fShapes:= TObjectList.Create;
  21.    TEllipse.Create  ('ELLIPSE',   Self);
  22.    THexagon.Create  ('HEXAGON',   Self);
  23.    TRectangle.Create('RECTANGLE', Self);
  24.  
  25.    // Set up ALL symbols ---------------------------------------------
  26.    fSymbols:= TObjectList.Create;
  27.    TArrow.Create('ARROW',Self);
  28.    TCross.Create('CROSS',Self);
  29. End;


Leider hab ich ein Problem bei der Registrierung, das ich noch nicht lösen konnte. Aber das ist ja jetzt eigentlich ganz egal. Ich wollte Dir das zeigen, denn das brauch ich. Und eigentlich könnte jedes Grafikprogramm so was gut brauchen.

Ich habe vier Basis-Grafik-Objekte:
1) TRGBA-Color
2) TRGBA-Image
3) TFreeType2Font
4) TRenderer

Bei den ersten drei Objekten gibts keine Ableitungen.

Der TRENDERER hat zwei Ableitungen:
TShape: zeichnet Widgets, das sind Formen mit Textur und einem Rand
**********davon abgeleitet: TEllipse,THexagon,TRectangle,TRoundRect, usw. (es gibt noch weitere) das ist ein nach oben offenes Konzept, weil der Renderer grundsätzlich mit Silhouetten arbeitet, die man auch laden können soll (TSomeShape.Load...)

TSymbol zeichnet Symbole, damit sind einfache Zeichnungen gemeint (Pfeile/Kreuze/Haken...)
**********davon abgeleitet:TArrow,TCross,THook,TSpot.........
Was aber wichtig ist: auch wenn man neue Zeichenprozeduren dazu erfindet, die Renderer-Schnittstelle ändert sich nicht mehr


Die Klassendefinitionen des TRenderer und Ableitungen:
Code:
  1. //********************************************************************
  2.    TRenderer = Class(TIDOwnedObject)
  3.    Private
  4.       Function EllipsePoint(Angle: Integer): TVertex;
  5.       Procedure OrthoSandBoxON;
  6.       Procedure OrthoSandBoxOFF;
  7.       Procedure Transform(ALeft,ATop,AWidth,AHeight: Integer);
  8.    End;
  9. //********************************************************************
  10.    TSymbol = Class(TRenderer)
  11.    Private
  12.       fSymbol: LongWord;
  13.       Procedure Build; Virtual; Abstract;
  14.    Public
  15.       Constructor Create(AName: String;
  16.                         AOwner: TCustomOwner); Override;
  17.       Destructor Destroy; Override;
  18.  
  19.       Procedure Show(ALeft,ATop,AWidth,AHeight: Integer;
  20.          AColor: RGBAColor; ASpecification: Integer); Virtual;
  21.    End;
  22. //********************************************************************
  23.    TShape = Class(TRenderer)
  24.    Private
  25.       fSilhouette: TList;
  26.       fTriangles: TList;
  27.       fShape: LongWord;
  28.       fFrame: TList;
  29.  
  30.       fFileName: String;
  31.  
  32.       // General static methods
  33.       Procedure AddVertex(ATexX,ATexY,AX,AY: Single);
  34.       Procedure BuildShape;
  35.       Procedure BuildFrame;
  36.       Procedure ClearLists;
  37.       Procedure ClearFrame;
  38.        Function Load: Boolean;
  39.       Procedure Triangulate;
  40.    Protected
  41.       // Specific methods
  42.       Procedure GenSilhouette; Virtual; Abstract;
  43.    Public
  44.       Constructor Create(AName: String;
  45.                         AOwner: TCustomOwner); Override;
  46.       Destructor Destroy; Override;
  47.  
  48.       Procedure Show(ALeft,ATop,AWidth,AHeight: Integer;
  49.          ADrawMode: TDrawMode;
  50.          AColor: TRGBAColor; AImage: TRGBAImage;
  51.          AFrameWidth: Integer; AFrameState: TFrameState);
  52.    End;


Das Farbobjekt TRGBAColor fällt aus der Reihe: es hat eine Funktionalität drin, die ich für die Widgets brauche: es kann Abstufungen einer Farbe machen ("Gradient").

Code:
  1. //********************************************************************
  2.    TRGBAColor = Class(TIDOwnedObject)
  3.    Private
  4.       fBaseColor: RGBAColor;
  5.       fShownColor: RGBAColor;
  6.  
  7.        Function GetColor: LongWord;
  8.       Procedure SetColor(AColor: LongWord);
  9.       Procedure SetBaseColor(ARGBAColor: RGBAColor);
  10.       Procedure SetGradient(AGradient: Single);
  11.    Public
  12.       Property RGBAColor: RGBAColor Read fShownColor Write SetBaseColor;
  13.       Property Red: Byte Read fBaseColor.Red Write fBaseColor.Red;
  14.       Property Green: Byte Read fBaseColor.Green Write fBaseColor.Green;
  15.       Property Blue: Byte Read fBaseColor.Blue Write fBaseColor.Blue;
  16.       Property Alpha: Byte Read fBaseColor.Alpha Write fBaseColor.Alpha;
  17.       Property Gradient: Single Write SetGradient;
  18.  
  19.       Constructor Create(AName: String; AOwner: TCustomOwner;
  20.                     ARGBAColor: RGBAColor); Reintroduce;
  21.       Procedure Reset;
  22.       Procedure Show;
  23.    Published
  24.       // Properties for loading/saving
  25.       Property BaseColor: LongWord
  26.          Read GetColor Write SetColor;
  27.    End;


So und was jetzt unsere eigentliche Schnittstelle betrifft, nämlich das Textur- und das Schriftobjekt, gib mir jetzt ca. eine Stunde, und ich bastle aus meinen Objekten einen Vorschlag für zwei Wrapper, weil meine Objekte eigentlich für einen Wrapper ungeeignet sind, ich hab z.B. das TRGBA-Image mit Funktionen vollgestopft, die nicht gebraucht werden, dh. ich muss hier Kürzungen vornehmen, und außerdem noch ein kleines Problem in den Griff kriegen, dass ich schon seit Wochen vor mir herschiebe. Wenn Dich interessiert, wie die Dinger wirklich aussehen: Dieser Thread, Seite 24, ganz unten: "GUI.ZIP", die fragliche Unit heißt GraphicSupport.

Bei allem, was ich sage, solltest Du allerdings bedenken, mit wem Du es zu tun hast. Ich mach jetzt OpenGL seit ca. eineinhalb Jahren und bin KEIN professioneller Programmierer. Das bedeutet für Dich, dass das, was ich jetzt sage, noch auf Richtigkeit abgeklopft werden muss und auch GANZ WICHTIG: auf Vorwärts-Kompatibilität.


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 427 Beiträge ]  Gehe zu Seite Vorherige  1 ... 25, 26, 27, 28, 29  Nächste
Foren-Übersicht » Sonstiges » Community-Projekte


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 17 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.042s | 17 Queries | GZIP : On ]