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

Aktuelle Zeit: Do Mär 28, 2024 21:33

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 ... 24, 25, 26, 27, 28, 29  Nächste
Autor Nachricht
 Betreff des Beitrags:
BeitragVerfasst: Fr Mär 30, 2007 13:13 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Code:
  1.  r:=GetRenderer(); // Render Komponente suchen oder Default Renderer erstellen und cachen


Meine Frage wäre: wer entscheidet, welcher Renderer erstellt wird? Ist das von der WidgetKlasse abhängig? Oder gibt er einen String mit? Von mir aus auch ein Enum, wie Sidorion vorgeschlagen hat. Aber irgendwas muss die Funktion GetRenderer ja mitkriegen.


EDIT: OK, hast ja recht, Lars. ist völlig egal, was man ihm mitgibt.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Mär 30, 2007 14:34 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Dez 28, 2002 11:13
Beiträge: 2244
Die Methode ist auf jeden Fall virtuell.

Da sind mehrer Varianten möglich:

1)Es ist denkbar, dass man den Renderer einfach als nicht-visuelle Komponente auch mit auf die Form setzt. Das ist natürlich am flexibelsten.

2)Die Form hat eine explizite Eigenschaft.

3)Die Komponente hat jeweils eine Eigenschaft Renderer.

4)Mehrere Möglichkeiten und wenn eins null ist wird in der übergeordneten Komponente gesucht.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Mär 30, 2007 15:35 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Ich halte im Augenblick bei Variante Nr.1. Mein derzeitiger "Renderer" ist einfach ein Teil des GraphTools (=Canvas) und daher statisch, aber erweiterbar. Wenn man eine neue Zeichenprozedur schreibt, erweitert man ihn. Das hat den Nachteil, dass jede Zeichenprozedur eine Frameprozedur braucht. Ich mache das im Augenblick so, dass meine Zeichenprozedur einfach zwei interne Zeichenprozeduren beinhaltet, eine "DrawArea" und eine "DrawFrame", wobei man sich entscheiden kann, ob man nur die Area oder nur den Frame zeichnet oder beides. Aufgerufen wird diese Zeichenmethode über einen Methodenzeiger, weil dieser leicht durch einen anderen ersetzbar ist (Stichwort Themes).

Es liegt nicht am Funktionieren, denn funktionieren müssen alle vorgeschlagenen Varianten. Für mich stellt sich die Frage, welche dieser Implementierungsarten am deutlichsten ist. Ich hätte gern, dass man hinschaut und sagt: "Na klar so geht das" und dass man dabei mit einer großen Wahrscheinlichkeit richtig liegt. Von diesem Blickwinkel gesehen ist die Renderer-Methode klar im Vorteil.


EDIT:
Das bedeutet: Ich tendiere eindeutig zu Deiner Variante Nr.3. Jedes Widget sollte seinen individuellen Renderer bekommen:
im Konstruktor den Klassen-Default-Renderer (kann ja auch ein Property sein, oder?). Themes kann ihm einen neuen zuweisen, und zwar genauso wie bei allen anderen Eigenschaften: aus einer Liste des GraphTool (so wie ichs derzeit mache), weil der Renderer jetzt - so wie alle anderen Visuellen Eigenschaften - ein Objekt ist. Damit mutiert mein Methodenzeiger einfach zu einem Objekt; die Vorgangweise bleibt dieselbe, wie ich sie jetzt im Augenblick habe. Und die Probleme bleiben auch dieselben: wenn mein Widget grundsätzlich alle Renderer bedienen können muss, müssen die Zeichenmethoden des Renderer genormt sein, es geht nicht, dass die Zeichenmethoden verschiedene Parameter entgegennehmen. Wozu brauch ich dann eigentlich ein Objekt? Ich habe keine Vorteile mehr aus der Vererbung.

Ja klar, wenn Du ein TElllipseButton aus dem TButton ableitest, OK. In diesem Fall können die abgleiteten Renderer wirklich verschiedene Zeichenmethoden haben. Das geht aber nicht. Ein TButton muss ein Allrounder sein, der mit allen Zeichenmethoden zurande kommt.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Mär 30, 2007 17:03 
Offline
Ernährungsberater
Benutzeravatar

Registriert: Sa Jan 01, 2005 17:11
Beiträge: 2067
Programmiersprache: C++
Zu einem Thema vor einer halben Seite *hust*

Zum Theme:
Defaulttheme und der User muss manuell laden.

;)

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Mär 30, 2007 17:40 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Jawoll, mein General. :wink:


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Mär 30, 2007 20:02 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Dez 28, 2002 11:13
Beiträge: 2244
Wenn man für jedes Objekt einen eigenen Renderer hat, hat man nicht viel gewonnen. Da könnte man auch direkt von der Komponente ableiten und die Zeichenmethode überschreiben. Die Idee ist ja den Code für gemeinsame Primitive auszulagern um ihn einfach austauschen zu können(=Theme). Daher muss diese Schnittstelle genormt sein. Die Schwierigkeit ist herauszufinden welche Elemente zu einem Theme gehören.

mögliche Elemente wären:
Rahmen: versenkt, erhöht, Fensterrahmen
Button-Hintergrund: gedrückt, oben, aktiviert,
einfacher Text
Bild
Pfeil
Checkbox-Kästchen: ausgewählt, normal
....

Vieles kann auch über Texturen gelöst werden.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Mär 31, 2007 16:04 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Hallo Lars,
ich habe gestern und heute drüber nachgedacht, was das beste wäre. Ich habs mir nicht leicht gemacht und habe versucht, mir die weitere Entwicklung vorzustellen, mit allen drei mir jetzt vorliegenden Varianten. Zuletzt bin ich zu forlgendem Schluss gekommen (ich vergleiche die Enum-Methode, meine Methoden-Zeiger-Methode und Deine Renderer-Methode):

Ich halte Deine Renderer-Methode für die Beste, weil
1) sie ist genauso funktionell wie die anderen beiden
2) sie ist genauso schnell wie die anderen beiden
3) sie hat den Vorteil der Kapselung aller notwendigen Routinen, die man für das Zeichnen eines Widgets braucht und ist daher m.E. besser gerüstet für zukünftigen Ausbau und ist trotzdem übersichtlich und verständlich

Daher werde ich die Renderer-Methode nehmen.
Danke
Traude


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Apr 02, 2007 08:15 
Offline
DGL Member

Registriert: Mo Dez 20, 2004 08:58
Beiträge: 442
Wohnort: Mittweida (Sachsen)
Was ich jetzt hierbei nicht verstehe ist folgendes:
Ein Knopf braucht Rahmen, Knopffläche (in verschiedenen Statusen), Text; Ein Edit braucht Rahmen, Eingabefeld, Text, ein Panel braucht Rahmen und Hintergrung (also auch wieder ne Fläche).
d.h.: Die ZeichenProzedur vom Knopf sieht so aus:
Code:
  1.  
  2.   If Pressed then Renderer.TextureRect(PressedTexID, left, top, width, height)
  3.   Else If MouseOver then Renderer.TextureRect(MouseOverTexID, left, top, width, height)
  4.   Else Renderer.TextureRect(NormalTexID, left, top, width, height);
  5.   If Default
  6.   Then Renderer.DrawFram(left,top,width,height);
  7.    Renderer.DrawTextRect(left,top,width,height,Caption);
  8.  

die vom Edit so:
Code:
  1.  
  2.   If Enabled then Renderer.TextureRect(EnabledTexID, left, top, width, height)
  3.   Else Renderer.TextureRect(DisabledTexID, left, top, width, height);
  4.   Renderer.DrawFram(left,top,width,height);
  5.   Renderer.DrawTextRect(left,top,width,height,Caption);
  6.  

usw.
Meiner Meinung nach sollte der Renderer also eine Menge von Zeichenroutinen bereitstellen, die das Widget rufen kann. Welche das sind, hängt von der Widgetklasse ab. wenn man also einen sechseckigen Knopf haben will, beerbt man einfach das Knopf-Widget und ruft statt TextureRect TextureHexagon. Bzw könnte man den 'Zeichenstil' auch mitgeben ala TextureShape(Left,Top,Width,Height,dsHex [oder dsRectangle, dsRoundRect]). Ich denke, Ihr geht zu speziell vor, d.h. die Zeichenroutine soll das ganze Wiget zeichnen.

_________________
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: Mo Apr 02, 2007 09:19 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Hier die Renderer-Klassen, wie ich sie derzeit habe (das TIDOwnedObject ist bloss ein Objekt mit einem Namen):
Code:
  1.    TDrawMode = (dmAll, dmShapeOnly, dmFrameOnly);
  2.    TFrameState = (fsFlat, fsRaised, fsLowered);
  3.  
  4. // Basis-Renderer *******************************************
  5.    TRenderer = Class(TIDOwnedObject)
  6.    Private
  7.       Procedure Shape(ALeft,ATop,ARight,ABottom: Integer;
  8.               AColor: TRGBAColor; AImage: TRGBAImage);
  9.                                      Virtual; Abstract;
  10.       Procedure Frame(ALeft,ATop,ARight,ABottom: Integer;
  11.               AColor: TRGBAColor; AFrameWidth: Integer;
  12.               AFrameState: TFrameState);
  13.                                      Virtual; Abstract;
  14.    Public
  15.       Procedure Draw(ALeft,ATop,ARight,ABottom: Integer;
  16.         ADrawMode: TDrawMode;
  17.         AColor: TRGBAColor; AImage: TRGBAImage;
  18.         AFrameWidth: Integer; AFrameState: TFrameState); Virtual;
  19.    End;
  20.  
  21. // Beispiel für einen Renderer **********************************
  22.    TRectangle = Class(TRenderer)
  23.    Private
  24.       Procedure Shape(ALeft,ATop,ARight,ABottom: Integer;
  25.          AColor: TRGBAColor; AImage: TRGBAImage); Override;
  26.       Procedure Frame(ALeft,ATop,ARight,ABottom: Integer;
  27.          AColor: TRGBAColor;AFrameWidth: Integer;
  28.          AFrameState: TFrameState); Override;
  29.    End;
  30.  


Ich bin gerade dabei, den Code auf den Renderer umzuschreiben, es funktioniert schon alles wieder, nur bei der Ellipse hakt es noch ein wenig. Die Schrift habe ich nicht im Renderer drin, weil bisher meine Drawing Procedure auch keine hatte. Schrift ist ja auch bloss ein Zeichenmittel, das man sich - wie den Renderer - aus einem "Pennal" holen und benutzen kann: siehe unten Button-Code. Ob ich die Schrift in den Renderer einbaue, weiß ich noch nicht.

Vermutlich fehlt noch eine Menge, was mir erst auffallen wird, wenn ich jetzt die Widgets mache. Das muss ich dann "On The Fly" nachholen.

Zitat:
Ich denke, Ihr geht zu speziell vor, d.h. die Zeichenroutine soll das ganze Wiget zeichnen.

Ich zeichne schon das ganze Widget. Du brauchst für einen sechseckigen Knopf keine abgeleitete Klasse, es reicht der TButton, dem Du einen Hexagon-Renderer gibst:
Code:
  1. MyButton.Renderer:= GraphTool.RendererByName['Hexagon'];


Der Button zeichnet gar nicht mehr, das macht seine Vorfahrklasse mit der Prozedur "TRenderer.Draw". Der Button stellt seine Zeichenmittel bereit, die man ihm per Theme oder auch individuell geben kann: Farbe/Renderer/Textur/Schrift, DAMIT sein Vorfahr damit zeichnen kann. Ansonsten kümmert sich der TButton nur um sein "Verhalten".
Unten der SourceCode für den (funktionierenden) TestButton (wie man an der Zeile mit der "//&&&&&"-Markierung sieht, habe ich noch Schwierigkeiten mit der Positionierung meiner FreeType-Schrift):

Code:
  1. Procedure TGUIButton.Paint;
  2. Begin
  3.    // HOVER berücksichtigen
  4.    If fRoot.HoveredItem <> Self  
  5.       Then fFrameState:= fsFlat;
  6.  
  7.    // Farbe einstellen
  8.    If fFrameState = fsRaised
  9.       Then FGColor.Gradient:= 0.7
  10.       Else FGColor.Gradient:= 0.5;
  11.  
  12.    Inherited Paint;
  13.  
  14.    // Schrift zentrieren und schreiben
  15.    fPosX:= Left + (Width Div 2)  - (Font.TextWidth(fCaption) Div 2);
  16.    If fPosX < 0 Then fPosX:= 0;
  17.    fPosY:= Top  + (Height Div 2) - (Font.TextHeight(fCaption) Div 2) - 10; //&&&&&
  18.    If fPosY < 0 Then fPosY:= 0;
  19.  
  20.    Font.Show(fPosX,fPosY,fCaption);
  21. End;




EDIT: Ha! Ein "FadeIn" funktioniert auch schon.


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

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Mich hat vor kurzem jemand gefragt, ob ich ein 3D-Widget (mit Triangle-Listen) machen würde. Ich sagte Ihm, dass ich jetzt endlich die 2D-Widgets bauen möchte und dieses Feature überhaupt nicht gefragt ist.

Allerdings hat dieser Jemand genau meinen wunden Punkt getroffen. Denn ich mache immer noch nur meinen Bounding-Box-Hittest mit den Punkten Links/Oben/Rechts/Unten. Für die ganz normalen Anwendungen ist das genug. Aber schon bei kreisförmigen Widgets seh ich mit diesem Hittest ziemlich alt aus. :(

Der neue Renderer kann runde Widgets zeichnen. Was macht er da? Er plottet Punkte auf einer Kreislinie und verbindet diese zu einem Polygon. Die Texturkoordinaten erzeugt er gleich mit. Er errechnet im Augenblick diese Punkte/ Texturkoordinaten bei jedem Rendervorgang neu.

Er könnte aber genauso die Punkte und Texturkoordinaten nur einmal rechnen, das ganze selbständig in Dreiecke zerlegen und die Daten dann in einer Punkte-Liste ablegen (braucht allerdings ein bissl Speicherplatz). Mit dieser Punkteliste könnte das Widget einen GESTALTGENAUEN Hittest machen.

Ob auch Animationen damit möglich sind, weiß ich noch nicht. Ist nur mal so eine nicht ausgegorene Idee.
>>unschuldig guck<< :roll:


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Apr 03, 2007 08:02 
Offline
DGL Member

Registriert: Mo Dez 20, 2004 08:58
Beiträge: 442
Wohnort: Mittweida (Sachsen)
Das ist ja eine prima Idee .. kannste das gleich mitmachen? :twisted: :twisted:
Nee Polygenau reicht völlig, Animationen müssen nicht sein. das muss dann der User durch Manipulation der Punktelliste oder sonstiger Eigenschaften am Widget selber machen.

_________________
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: Di Apr 03, 2007 08:46 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Ich frag ja nur, weil man mir anfangs (vor vielen, vielen Seiten) unmissverständlich zu verstehen gegeben hat, das so etwas nicht gewünscht ist. Nur jetzt wäre es einfach ein Nebeneffekt bei der Implementierung eines besseren Hittest. Ist natürlich eine Ausrede von mir. Ich wollte das immer schon dabei haben. :P


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Apr 03, 2007 09:37 
Offline
DGL Member

Registriert: Mo Dez 20, 2004 08:58
Beiträge: 442
Wohnort: Mittweida (Sachsen)
Ich find ja wabbelnde Knöppe auch geil, also wenns eh abfällt, dann leg los :lol:

_________________
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: Di Apr 03, 2007 09:41 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2621
Wohnort: Berlin
Programmiersprache: Go, C/C++
Naja das ich der "jemand" war kannst ruhig sagen :wink:.
Ich hab das Polygonbasierte Prinzip schon ziemlich weit implementiert und werde wohl in kürze die widgets umstellen. So kommen allerdings auch neue funktionen hinzu. Neben dem AddVertex für die Liste gibt es vorgefertigte Befehle z.B. addRoundShadedBox wo man dann die anzahl an punkten für die rundung der ecken mit angeben kann.

_________________
"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 10:02 
Offline
DGL Member
Benutzeravatar

Registriert: Di Okt 03, 2006 14:07
Beiträge: 1277
Wohnort: Wien
Hm. Man könnte an das AddVertex einen Loader anschliessen. Ist ja nicht so abwegig, oder?


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 ... 24, 25, 26, 27, 28, 29  Nächste
Foren-Übersicht » Sonstiges » Community-Projekte


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 31 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.054s | 17 Queries | GZIP : On ]