Apropops 'viereckiges Plätzchen': Könnten wir nicht so ne art Borderpoly einbaun? bei Edits wäre das natürlich rechteckig, aber dann könnte man z.B.: pfeilförmige Knöppe, oder den Knopf zum Aufklappen bei der ComboBox sechseckig machen.... ist aber nur ein Vorschlag.

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

Hatte da auf Seite 13 schonmal was zu beliebigen Formen geschrieben. Wenn dann sollte man das wirklich beliebig und nicht nur als Polygon erlauben.

Wenn Du möchtest, kannst Du auch ne Gauss'sche Glockenkurve drauf zeichnen.


Was ich vermeiden möchte: dass wir bei den honorigen Vierkantfenstern enden. Als Fallback, ja, klar. Aber sonst: bitte nicht.

wieso nicht einfach einen Alphatest und dass bei durchsichtigen Stellen der Klick durchgeleitet wird? Oder besser noch eine methode die angibt ob eine bestimmte koordinate zum Control gehört, oder nach hinten geleitet wird.

Lars schrieb (irgendwo auf Seite 12, glaub ich):


Das ist schon alles, was man braucht.

Hier ein Versuch für die hoffnungsvolle Evolution eines Rechtecks:

Parameter für ein flaches, randloses Rechteck:
· Color ist eine RGBA-Farbe (das gilt für alle Farben)
· BackgroundColor
· Left,Top,Width,Height (oder: Right,Bottom statt Width,Height)
oder auch: TopLeft, BottomRight (als 2D-Punkte, bietet mehr Möglichkeiten für die weitere Entwicklung, um andere geometrische Figuren darzustellen: unregelmäßige Polygone, oder auch mehrere Dreiecke zum Beispiel)

Zusätzliche Parameter für ein flaches Rechteck mit flachem Rand:
· BorderColor
· BorderWidth

Ich würde, um das jetzt wirklich darzustellen, 5 Vierecke zeichnen:
· Zunächst den Untergrund mit BackgroundColor, wenn das Rechteck nicht den gesamten Untergrund bedeckt
· ein Rechteck in der Mitte mit der Farbe Color (die Front), die Eckpunkte muss ich mir natürlich ausrechnen
· und vier Trapeze drum herum mit der Farbe BorderColor.

Zusätzliche Parameter für ein erhöhtes/vertieftes Rechteck (wie ein Button):
· State = Flat/Raised/Lowered

Hier braucht man Abstufungen für die BorderColor, denn die BorderColor simuliert nur einen flachen Rand. Z.B. könnte man eine Prozedur haben, die eine RGBA-Farbe in der Helligkeit verstellt, und hat dann automatisch jede Schattierung von BorderColor zur Verfügung. Damit kann man die Abschrägungen zeichnen und man braucht nur eine einzige Rechteck-Zeichenroutine für das alles

Zusätzliche Features:
· Font: stellt einen Text auf dem Rechteck dar
· Textur: kann sowohl über den ganzen Knopf gezogen werden als auch nur über das Frontrechteck (es wären Texturkoordinaten nötig). Die Farben drunter können bleiben, weil sie mit der Textur verrechnet werden und damit ihre Schattierungsfunktion behalten ==> ermöglicht Platzersparnis bei den Texturen



Jetzt fällt mir nichts mehr ein.

Ich habe im Internet auch runde Knöpfe gesehen, die so gezeichnet wurden. Für mich haben die aber nicht überzeugend ausgesehen im Gegensatz zum Vierecks-Knopf, der mit dieser Methode wirklich glaubhaft ein erhöhtes Rechteck darstellen kann. Für andere geometrische Figuren (Dreiecke, regelmäßige/unregelmäßige Polygone, Ellipsen/Kreise, Vierecke mit abgerundeten Kanten, etc.) braucht man je eine Zeichenroutine.

Traude

Komme mir irgendwie allein vor heute. Na, macht nichts. Ich lege trotzdem noch ein Schöppchen nach:

Ich bin wieder einmal in mich gegangen, um meine wirren Gedanken in Bezug auf den Themes-Manager zu ordnen. Hier ist das Ergebnis:


Der GUI-Manager besitzt einen Theme-Manager, der für die Verwaltung der Themes-Eigenschaften zuständig ist. Themes Eigenschaften sind visuelle Eigenschaften, die eine Zentrale Verwaltung nahe legen, weil sie von vielen Baumelementen benutzt werden, und der GUI Baum dadurch ein einheitliches Erscheinungsbild erhält. Der Themes-Manager hat auch für das Laden und Speichern dieser Eigenschaften zu sorgen.

Die Themes-Eigenschaften liegen folgendermaßen vor:
· als Objekte des Themes-Manager (hier befindet sich die wirkliche Instanz), organisiert in einer Liste
· als Published Properties des TGUIItems (diese sind ledigliche Zeiger)

Themes-Eigenschaften dürfen nicht vom TGUI-Item gespeichert (im Sinne von: an den DataProvider weitergegeben) werden, sondern es wird nur der Listenindex gespeichert, den diese Eigenschaft in der Liste des Theme-Managers innehat. Die TGUIItems müssen also fähig sein, diesen Index zu ermitteln.

Die Themes-Eigenschaften werden "baum-mäßig" weitergegeben, das heißt, wenn ein Element im Baum z.B. eine eigene Font (mit Listenindex <> 0) hat, so haben auch alle seine Nachkommen diese Font, außer sie haben wieder eine eigene usw.

Das ist ein PROBLEM wenn z.B. nur das Chef-Element eine besondere Schrift (Überschrift) hat, die Children aber die übliche "Uniform" haben sollen.


Themes-Eigenschaften sind eine Teilmenge der visuellen Eigenschaften. Eine beispielhafte Aufzählung:

· Vordergrund-/Hintergrundfarbe
· Textur
· Schrift
· ...?

Keine Themes-Eigenschaften sind (weil nicht erwartet werden kann, dass ihre Weitergabe im Baum sinnvoll ist, da es sich um hochgradig individuelle Eigenschaften handelt):

· Zeichenroutine
· Left/Top/Width/Height bzw. die Liste der 2D-Punkte (siehe mein voriger Beitrag)
· ...?

In der Hoffnung auf etwas mehr Echo
Traude

Geh am einfachsten über den Namen des Themes, der Listeneintrag kann sich mit der Anzahl der Themes verändern.


An der Stelle muss man mächtig aufpassen, denn sobald man etwas an der Schrift des Kindes ändert betrifft die Änderung automatisch alle Elemente die die Schrift auch verwenden. An der Stelle wäre es besser, wenn jedes Element eine eigene Schrift besitzt, diese aber die Werte des Vorgängers hat.
Funktioniert aber nur solange gut wie die Schrift richtig aufgebaut ist. In X-Dream ist TXD_Font nur eine Art Verweis auf eine 'richtige' interne Schrift sodass TXD_Font relativ klein ist und man ohne Probleme mehrere Kopien davon erzeugen kann. TXD_Font sagt bei einem Aufruf nur dem Fontmanager, dass er die passende interne Font aufrufen muss. Somit existiert für beliebig viele Kopien nur eine interen Font. Wenn jetzt aber die Font der internen Font entspräche würde eine Kopie mächtig weh tuhen.
Hier müssten wir aufpassen, weil wir dann quasi ne Einschränkung an die Font richten.


Wo ist da ein Problem?
Entweder man hat eine Defaultschrift oder man nimmt die Schrift des Parents. Bei jeden der Teile hat man Probleme.
Wobei es in der Praxis eh irrelevant sein wird, da man die Schrift der Elemente nur jeweils einmal ändern müsste und es danach gespeichert ist (In der binär oder XML Datei )


Ich kenne mehre Programme bei denen ich nicht glaube, dass die Zeichenroutine nicht gewechselt wird. Da müsste man noch genauer schauen.

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

Guten Morgen

I0n0s schrieb:


Nein, ich meinte das eigentlich so: Die Eigenschaft "Farbe" ist im TGUIItem nur als Zeiger auf einen Listeintrag im Themes-Manager vorhanden. Das Item muss eigentlich nur speichern: "Color = No3" (of Themes "XYZ" Colors).
Der Themes-Manager müsste speichern: "ColorList: Color 0 = LightBlue, Color 1 = Magenta, ......


I0n0s schrieb:


Für mich ist das deshalb ein Problem, weil man eigentlich erwartet, dass beim Erzeugen des TGUIItems es alle Eigenschaften des Parent mitbekommt. Eine richtige Vererbung von Eigenschaften, aber baum-mäßig (es erbt sozusagen nicht nur die Struktur des TGUIItems sondern auch die Variableninhalte von seinem Parent). Wenn jetzt das Parent eine nicht-Standard-Font hat, müsste es eigentlich dem Child folgerichtig auch diese Nicht-Standard-Font weitergeben, wenn es sich standardmäßig verhält. Im Fall der Themes sollte aber das Child doch die Standard-Schrift kriegen. Ein Problem ist das aber nur bei der Erzeugung des TGUIItems.

Wenn Du später die Farbe eines bestimmten Elements änderst: "MyWindow.Color:= LightGreen" sollte das eigentlich keine Auswirkungen auf die Children haben. Die SetColor-Methode ist komplizierter: sie muss nachsehen, ob es "LightGreen" in der ColorList des ThemeManagers schon gibt, wenn nicht, muss es einen neuen Listeintrag anlegen und dem Element einen Zeiger darauf verschaffen).

************************************************
NACHTRAG, WICHTIG: Das Child "hat" seine Schrift gar nicht, nur als Zeiger, AUCH wenn es eine Nicht-Standard-Schrift ist. Die richtige Instanz davon sitzt im Themes-Manager, nur dieser besitzt die Eigentumsrechte (Schrift 0, Schrift 1,...). Ist auch sinnvoll, wenn alle Schriften neu geladen werden müssen (da gibts im Windows so einen Fall beim Fenster-Resize). Dasselbe gilt für alle Themes-Eigenschaften. Man sollte hier auch das Feld "Owner" einführen.
************************************************

I0n0s schrieb:


Ja da hast Du recht. Ich hab da scheints etwas verwechselt: Die Weitergabe der Themes im Baum und ob es grundsätzlich eine Themes-Eigenschaft sein soll. Eine Weitergabe der Zeichenroutine vom Parent an das Child ist Unsinn (Parent=Knopfleiste, Child=Knopf: die Zeichenroutine ist jedenfalls anders), andererseits handelt es sich bei der Zeichenroutine offenbar um eine Themes-Eigenschaft.

Traude

Sieht aus, als ob Ihr alle einverstanden wärt. Ich werde das Grobkonzept nochmals auf den neuesten Stand bringen und morgen vormittag wieder hereinstellen, Updates bei
1) Fehlerbehandlung
2) Themes-Manager

Dann ist es von mir aus gesehen fertig.

Traude

Ich melde mich mal wieder.

Ich hab einige Tage nichts von mir hören lassen, da ich wieder mit WOW angefangen hab und am anfang man viel Zeit braucht.
Das legt sich in der Regel nach 1-2 Wochen und man hat mehr Zeit.

Zu deinen Letzten Post, zum Thema Theme Manager, bin ich auch der gleichen Ansicht.

Ich habe beschlossen die GUI in XD fallen zu lassen und in der nächsten oder übernächsten release dann die sogenannte DGL_GUI zu implementieren.
Dies bedeutet auch, dass ich mich als vollzeit Programmierer für das Projekt betätigen werde.
Wenn es dann so weit ist, wird Phobeus uns schon ein Platz auf dem SVN Repo geben und dann wird es seinen Lauf nehmen.

Ich denke, wir werden in kürze das Pflichtenheft anfertigen können.
Wenn dieser Prozess erreicht ist, dann werden sowieso noch einmal einige Unstimmigkeiten geklärt werden.
In der Regel wird es auch im Programmierungsprozess noch überarbeitet, da einige Realisierungen änderungen zu Folge haben.

Ein SDL 1.2 support kann z.B. für die GUI nicht geben, da der Multi Window Support fehlt.
Dieser ist erst in 1.3 mit drin und das ist noch im Entwicklungsrepo von libSDL.

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

Projekte: https://github.com/tak2004

Hallo,
anbei wie versprochen das neue Konzept.

Wie gesagt, Updates bei
4) Fehlerbehandlung
5.4) Einbinden des Themes-Managers

aber auch bei
3) Funktionen der TGUIDescendants: hier habe ich nur eine Klarstellung eingefügt, dass das "Feel" von "Look and Feel" jedenfalls jetzt nicht implementiert wird.



Aber ich würde auch gerne wissen, wie ihr das Feinkonzept aufstellen wollt, kann man das eventuell auch im SVN-machen? Denn so wie bisher können wir nicht weitermachen, das dauert einfach zu lang.
Traude

Das Pflichten Heft könnte man auch im Wiki machen.

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

Projekte: https://github.com/tak2004

Hätte auch den Vorteil, dass andere, die sich an so ein Projekt wagen wollen, mal sehen können, wie sowas aussieht.

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

Ausserdem muss man auf nichts warten, sondern kann sofort los legen.
http://tak2004.dyndns.org/share/surfshop.pdf Das ist ein Beispiel für ein Pflichtenheft im Anfangsstadium.
http://wiki.delphigl.com/index.php/DGLGUI_Pflichtenheft Hier hab ich mal die Grundlage für das Pflichtenheft angelegt[/code]

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

Projekte: https://github.com/tak2004