Man könnte sich das auch so vorstellen:
Es gibt IMMER einen Theme-Manager, wenn keine speziellen Themes installiert sind, agiert eben der Default-Theme Manager. Die Elemente besitzen gar keine eigenen Zeichenroutinen, sondern beauftragen dafür immer jemand anders.

Das wäre mir sogar noch lieber. Allerdings sollte in diesem Fall auch eine Owner-Draw-Möglichkeit gegeben sein, sodass man z.B.: eine Combobox mit Checkboxen in den Items realisieren kann, oder sowas perverses, wie eine Combobox, mit der man Zahlen von -999 bis 999 mit max. 3 Clicks eingeben kann (das Ding hat mich in VCL Wochen gekostet. War quasi ne Matrix mit Zahlen von 00 bis 99 mit ner Knopfleiste links, wo man das Vorzeichen und die Hunderter einstellen konnte), oder ein multi-state-Knopf.

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

toll...seite 15....keine zeit am wochenende fürs UML gehabt und es geht munter weiter... *sich gerade überfordert fühl*

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

Hallo Tak,

Tak schrieb:

OK schreib ich noch dazu

Tak schrieb:

Hm ja, warum nicht? Das GUI ist ja "blind" und zeichnet ins Leere. Es weiß gar nichts davon, dass seine Kinder irgendwie getrennt sind. Und jedes (Fenster-) beinhaltet seine Unter-Elemente.
Wenn Du nur EINES dieser Fenster neu zeichnen willst, darfst Du dich jedenfalls nicht an den GUI-Manager wenden, sondern an das jeweilige Fenster. Könntest aber auch für jedes Fenster einen extra GUI-Manager erzeugen.

Tak schrieb:

Wenn ich einem GUI-"Zweig" die Möglichkeit gebe, aufs zweite Canvas-Objekt umzusteigen, dann sollte das möglich sein.

Tak schrieb:

Das überlasse ich Dir.

Tak schrieb:

Wenn Du grad so schön in Fahrt bist: eine IDE wäre auch nicht schlecht.
Traude

@Tak: Ich steh grad aufm Schlauch.. was meinst Du mit GPU und CPU Canvas?

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

@Tak: das mit dem Zweigsystem finde ich gut, ich meine das so:
Bisher hatte ich das Themes-Konzept so gedacht, dass der Themes-Manager Vorgaben für den ganzen Baum gibt. (was z.B. die anderen Dinge nicht betrifft: wenn ich sage "MyWindow2.Draw" wird nur dieser Teilbaum gezeichnet, also dieses Fenster mit allen seinen Nachfahren)
Dh. ich muss beim Themes-Manager auch bisschen mehr "baummäßig" denken.

@Sidorion:
er meint nur dass der Wrapper (der fürs echte Zeichnen zuständig ist) mehr als nur eine Grafik-Library anbieten könnte. Der GUIManager kümmert sich nicht darum, wo gezeichnet wird. Das muss der Wrapper tun. Du kannst dieses System theoretisch genauso mit einem Windows-Fenster benutzen, oder mit DirectX, oder mit SDL. Der GUIManager verlangt nur: zeichne ein Viereck! Wo und wie ist ihm wurscht. Aber derzeit verwendet er nur EINEN Grafik-Wrapper, und in diesem gibts derzeit nur EINE Routine für, sagen wir mal: einen Kreis. Und wenn die Kreisroutine Opengl-Befehle benutzt, ist man auf OpenGl festgelegt.

GPU und CPU Canvas sollte recht schnell erklärt sein.
Es gibt OpenGL und DX als GL die die GPU ansprechen und dann gibs halt noch alles andere die die CPU ansprechen.
Beide Canvas Objekte sollten das gleiche Interface haben aber dahinter gehts halt anders ab.
Ideal wäre zu sagen, eine Klasse TAppWindow hat ein Attribut GraphicInterface und das kann GI_GPU oder GI_CPU sein.
Je nachdem wird dann für Canvas das GPU oder CPU Objekt genutzt.
Hinter dem GPU Funktionen kann dann OpenGL, DirectX, OpenGL ES oder Consolen Spezifische grafik libs liegen und hinter CPU liegen dann libs wie Mesa, SDL, X11, WinAPI,... .

Mein Canvas Objekt besitzt ca 13Funktionen die dafür sorgen verschiedene arten von rechtecken zu zeichnen, Fonts zu erstellen und zeichnen und Texturen zu Laden und zu zeichnen.

Zum Thema Theme Manager hab ich einiges zu sagen.
Erstmal muss festgelegt werden was so alles zu einem Theme gehört.
Meiner Meinung und auch umsetzung sind, dass das Farbschema, Border, Schrift und Bilder.
Hier ein bischen detailierter.
Font:
-Size
-Name
-Color
-SelectedColor
Border:
-left
-right
-top
-bottom
Bilder:
-name
Farbschema:
-highlight
-face
-shadow
-titlebarcolor1
-titlebarcolor2
-selected
-editcolor

Das ganze wird in States gepackt, damit man für jeden Status wie Active, Pressed, ... dieses einzeln festlegen kann.
Ich habe den Thememanager alle Componenten gegeben und über einen Namen fragt die Komponente nach den Daten und zeichnet dann in draw event je nach zuweisung den Fallback oder halt das Theme.
Die übergabe der Daten könnte so aussehen.
Der Theme Manager erstellt eine Klasse Font und die ist das default und wenn der user dann an einem Widget die Font Klasse ändert wird für dieses eine neue Font Klasse erstellt. auf diese Art wird nur beim initialisieren der Klasse einmal alles vom Theme Manager geladen und muss nicht ständig erneut abgefragt werden.
Wenn dann ein neuer Theme geladen wird zeigt ja das Widget auf das Font vom Manager und wird somit sofort aktualisiert oder im Fall vom cusomized Widget bleibt es halt in seinen Einstellungen.
Es sollte auch schon ein Defaul Setting für das UrWidget geben, sodass jedes neue Widget immer Daten zur verfügung hat.
Sachen wie verschiedene Schritfgrößen und Farben für unterschiedliche Widgets ist eher blöd und langsam.
Es gibt zig Bücher zum Thema GUI Design und das erste was wir gelernt haben, ist dass man einheitliches Aussehen beachtet.

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

Projekte: https://github.com/tak2004

Einheitlichkeit schön und gut, aber die Möglichkeit, dass ein Widget eine andere Schrift oder Farbe haben kann, sollte es schon geben. Manchmal gibts ja auch einen guten Grund dafür, etwas hervorheben zu wollen. Klicki bunti ohne tieferen Sinn ist Missbrauch.

Ich denke, zunächst solten wir Begriffe klären: man sollte zwischen Farbschema unt Theme unterscheiden.
Bei einem Farbschema wird quasi mit ohne Texturen gearbeitet, da kommen Attribute, wie font.color oder Border.left und so zum Einsatz. Bei einem Thema spielen Farben überhaupt keine Rolle, da alles texturiert ist und Rahmenbreiten, Font usw. werden auch über das Thema bestimmt.
Vergleichbar etwa XP mit und ohne Luna. Ohne gibts Farbschemas (malve,...) und mit gibts die drei Themenvarianten (standard, silver, olive)

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

@Sidorion: Aber die Schrift wird von der Textur ja nur soweit beeinflusst, dass sie eine Kontrastfarbe haben sollte, denn sonst ist sie nicht mehr lesbar, oder seh ich das falsch?



@Nachtrag: Ich habe grade meinen Firefox auf ein anderes Theme umgestellt, und dieses verwendet für die Knöpfe eindeutig andere Zeichenroutinen als das Default-Theme.

Als ich über dieses Thema nachgedacht habe, habe ich die Firefox-Themes angesehen. Und ich bin zu der Erkenntnis gekommen: Der Begriff "Themes" ist ein weites Feld. Jeder scheint es anders zu verstehen. Und ich habe es für mich so definiert: es ist offenbar etwas, was das Erscheinungsbild ändert. Wie es das Erscheinungsbild ändern kann, ist davon abhängig, wieviel das GUI zu ändern erlaubt.

@Nochmal Nachtrag: der Firefox muss bei Theme-Änderung neugestartet werden.

Was ich meine, war: In VCL kann man, wenn keine Themes aktiviert sind, die Schriftfarbe vor dem Canvas.Textout ändern, wenn die Themes aktiv sind, ruft man nur ThemeManager.TextOut mit einem bestimmten Widgettyp(z.B.: Button) und der ThemeManager weiss dann selber, welche Farbe die Schrift haben muss, denn die ist im XP-Theme hinterlegt (und kann imho auch nicht geändert werden, da in diesem Falle Windows die 'Schreibarbeit' übernimmt).

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

Naja, aber dasselbe Vorgehen wäre auch bei einem Farbschema denkbar. Wenn ich ein schönes Ensemble mit zwei gut aufeinander abgestimmten Farben habe (ohne jede Textur), ist es auch nicht so hübsch, wenn mir jemand mit einer grellen Schrift-Farbe dazwischenpfuscht.

Was ich mit dem Beitrag mit dem Firefox-Themes gemeint habe, war:

Das GUI gibt vor, wie ein Theme das Aussehen ändern darf. Und das bedeutet für uns: wir sitzen an der Quelle und können es uns aussuchen. Wir müssen uns in keinster Weise einschränken (nun ja bestimmte Grenzen gibts natürlich: wenn man alle Knöpfe, die vorher viereckig waren, plötzlich rund macht, ragt die Caption vielleicht über den Knopf hinaus).

Wir können Themes so auffassen, dass Farschemas dabei sind oder auch nicht. Wir können dem User die Möglichkeit geben, bei einem Theme die Schriftfarbe DOCH zu wechseln, oder auch nicht. (He! ich könnte hier - sozusagen über die Hintertür - 3D einführen, wechsle bloss die Zeichenroutine und den Grafikwrapper). Auf meinem viereckigen Plätzchen darf ich machen, was ich will.
Traude

Du meinst, dass die GUI in eine DLL soll?
Wenn ja frage ich mich wie du das mit dem OOP lösen willst?
(Ok, angeblich sei im Forum ne Lösung versteckt, ich bin aber zu faul zu suchen )

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