Du rupfst mir gerade einen dicken Haarschopf meines Konzepts aus. Der Themes-Manager hält in meinem Konzept die Themes-Objekte, und wenn man den Themes-Manager neu befüllt - was man jederzeit tun kann - , muss man die Elemente gar nicht benachrichtigen, weil sie Direktzeiger auf die jeweilige Themes-Objekte haben und es ihnen gar nichts anderes übrigbleibt, als anders auszusehen, und zwar sofort.

Weihnachten ist vorbei.

Ich habe wieder was ins Pflichtenheft geschrieben (in die technische Spezifikation ganz unten), es ist aber nicht viel:
http://wiki.delphigl.com/index.php/DGLGUI_Pflichtenheft#ANHANG:_Technische_Spezifikation

Ich kaue derzeit noch an einem Problem, wie man diese visuellen Eigenschaften am besten umsetzt. Außerdem wäre es auch ganz gut, wenn man die Events ähnlich behandelt, die brauchen fürs Script ja auch einen Namen.
Traude

Versuch es durch reverse Engineering zu machen.

Ein Button besteht aus einem Rand und einer Fläche die umrandet ist.
Der Rand besteht aus highlight-und shadowcolor.
Die Füllfläche besteht aus einer ButtonFaceColor Farbe.
Wenn der Button gedrückt wird, werden die Randfarben invertiert.
Auf dem Buton wird ein Text gezeichnet.

Farben:
-highlightcolor
-facecolor
-shadowcolor
-fontcolor

Zeichenfunktionen:
-zeichne linie
-zeichne rechteck
-->zeichne umrandetes rechteck
-zeichne Font

Eine Checkbox besteht aus einem Rand, einer Fläche, die Umrandet ist und einem Symbol(für aktiviert).
Die Fläche wird wie bei einem Button gezeichnet nur die Facecolor ist eine andere Farbe.
Über dieser Fläche wird bei Checked=true das Symbol gezeichnet.

neue Farben:
-Symbolcolor

neue Zeichenfunktionen:
-zeichne Symbol

Das machst du nun für alle Kompos und das was du am ende raus bekommst ist genau das, was du brauchst.
Ich habe das Symbol z.B. aus 2 Linien generiert und mir damit ein bischen platz gesparrt.
Meine Canvas2D Klasse hat ~12 Zeichenfunktionen für Font, Image und Widgets.

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

Projekte: https://github.com/tak2004

Ich habe letzte woche mal ein bischen Prototyping gemacht und mit Application windows gespielt.
Im Brainstorming hatten wir ja fest gelegt, dass der GUIManager erstmal Application Windows braucht um dann darauf ein Widget oder ein weiteres Fenster zu legen. Meine Testapp erstellt Appwindows und je nach GraphicInterface wird winapi oder ogl genutzt.
Ich war zu faul ein mini Fontmanager zu schreiben, drum hab ich zum test einfach eine pyramide gezeichnet.
Eigentlich sollte man den Fontmanager hinzu packen und dann den gleichen text schreiben.
Ich wollte noch eine X11 und SDL inc files hinzu legen aber sdl 1.3 hab ich die dll nicht compiliert bekommen und mein linux ist gerade erst wenige tage alt und noch nicht fertig eingerichtet.
http://tak2004.dyndns.org/share/DGLGUI.zip

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

Projekte: https://github.com/tak2004

Hallo,
Das mit dem Reverse Engineering mach ich.

Zu dem DrawLine etc. hätte ich eine Anmerkung:

1. Möglichkeit: man schreibt dem Grafikwrapper detailliert vor, WIE er zu zeichnen hat, indem man eine Box dezidiert mit Linien in der GUI vorgibt.

2.Möglichkeit: man lässt dem Grafikwrapper beim Zeichnen möglichst viel Freiheit. Das heißt, man gibt z.B. für eine Grafikroutine vor: Zeichne Box mit schattierten Rändern (ich glaube Du nennst das GradientBox).

Der Vorteil der zweiten Möglichkeit ist, dass der Grafikwrapper besser optimieren könnte, weil er nicht so festgelegt ist. Ich würde daher eher zur zweiten Möglichkeit raten.


Was die Zusatzprogramme betrifft: ich hab so was ähnliches auch, und es gibt ja auch EasySDLFont, das wäre ja was. Da können wir dann ein bißchen gustieren, welches wir nehmen wollen.

Übrigens: das mit der Themes-Laufzeitfähigkeit habe ich so im Pflichtenheft als Wunschfeature dringelassen, wie es I0n0s umgeschrieben hat (Tut Euch Ja denk ich mal nicht weh, wenn's dann doch dabei ist. ^^). Das mit dem OpenGL 1.1 musste ich rausnehmen, verstösst eindeutig gegen die Vorgaben.



@NACHTRAG:
Tak, ich habe mir Dein Multi-Window-Programm runtergeladen. Ja, gut! Super! Ich schlage mal vor, dass ich den Code, den man derzeit mit dem Konzept umsetzen kann, einfach mal schreibe und morgen abend dazustelle und wir uns ansehen, wie sich das am besten zusammenstöpseln lässt.

Ich bin für 2. und was du meinst ist bei mir



Das ist bei mir die Funktion um eine box mit übergang von farbe 1 in farbe 2 zu realisieren.
Die funktion hab ich für z.B. die Titelleiste eines Fensters hinzu gefügt.

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

Projekte: https://github.com/tak2004

Ich sehe gerade die Qualitätsanforderungen und bin mit einigen punkte nicht so einverstanden und da sollte eventuell mal diskutiert werden.
Sicherheit:normal
Fehlertoleranz:normal
Anpassbarkeit:nicht relevant
Installierbarkeit:nicht relevant
Ich bin eher für die ersten drei auf gut und installierbarkeit auf normal.
Man sollte schon ein script haben, welches ein die arbeit beim confen abnimmt und die gewollte platform korrekt etabliert.

edit: Ich kann nierends etwas zum GUI Editor finden. Der schein wohl unter gegangen zu sein.

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

Projekte: https://github.com/tak2004

Hallo Tak,

1) Sicherheit: normal
Habe ich mal so hineingeschrieben wegen dem Script. Wenn Sicherheit eine Stufe erhöht wird, müsste man da etwas zusätzliches tun, find ich

2) Fehlertoleranz: normal
Das habe ich so verstanden: Die GUI reagiert auf auftretende Fehler mit den üblichen Mittel: Fehler anzeigen oder, wenn das nicht möglich ist, in ein Logbuch schreiben und die Folgen verarbeiten. Keine darüberhinaus gehenden Massnahmen ergreifen. Ich konnte mich nicht entscheiden, ob das "gut" oder "normal" ist

3) Anpassbarkeit: nicht relevant
Das ist für mich nicht relevant, weil die größtmögliche Anpassbarkeit (zumindest was das Aussehen betrifft) gewährleistet sein muss. Das heisst, die völlige visuelle Anpassbarkeit über den Themes-Manager ist eine Grundvoraussetzung der GUI. Und die Anpassung der Events haben wir ja in der Diskussion ausgeschlossen. Die Anpassbarkeit der GUI, was die Plattform betrifft, ist ebenfalls bereits in der Definition die größtmögliche. Das war bereits am Anfang klar. Daher ist das Kriterium der Anpassbarkeit eigentlich hier vom Tisch. Aber vielleicht hast Du recht, man könnte durchaus auch "gut" schreiben (ich denke manchmal in Spiralen ).

4) Installierbarkeit: nicht relevant
Darüber habe ich mir eigentlich keine großen Gedanken gemacht. Wenn die GUI aus Pascal-Units besteht, muss sie zusammen mit dem Hauptprogramm kompiliert werden und die Installation ist eigentlich Sache des Hauptprogramms.



Last not Least: einen GUI-Editor haben wir nicht behandelt. Aber wenn wir die GUI ordentlich implementieren, sollte ein Editor nicht mehr so schwer zu machen sein.

Zum ersten hab ich in meiner geistigen umnachtung ein fehler gemacht.
Sicherheit sollte nicht relevant sein.

Die Fehlertoleranz siehst du auf einer anderen weise als ich , ich denke da viel mehr an Programmierer A kann nicht Wert B eintragen, wenn ein Wert C erlaubt ist. Also Falsche eingaben, fehlende Eingaben und einiges in diese richtung.

Bei der Anpassbarkeit ist es wie bei der Fehlertolleranz, ich denke da z.B. an neue Komponenten, andere Platformen.

Wir hatten uns ja darauf geeinigt, dass wir wrapper verwenden und man will doch auch den richtigen nutzten.
Um dies zu gewehrleisten sollte man ein Script hinzufügen.

Zur Tabelle selber hab ich auch was zu sagen. Man geht davon aus, was für das Projekt wichtig ist und was nicht und darauf hin werden ja die Teile in Muss und Kann Prirorisiert. Wenn du in Muss Bedingungen Theme packst dann muss auch in der Tabelle Anpassbarkeit in der Wertung hoch steigen.

Zum GUI Editor, wir haben darüber gesprochen nur nichts konkretisiert.

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

Projekte: https://github.com/tak2004

Leider kann ich nicht wie versprochen heute mit dem Basis Code aufwarten. Ich habe heute zu sehr herumgetrödelt und bin noch nicht fertig. Ich möchte mich dabei nicht hetzen, sonst kommt Murks raus. Ich melde mich morgen wieder.
Traude

Hallo an Euch alle.

In den letzten drei Tagen habe ich emsig versucht, das, worüber schon Einigkeit besteht, in Code umzusetzen. Aber es ist noch nicht lauffähig. Ich möchte Euch aber gerne etwas zur Verfügung stellen, was wenigstens schon ein bisschen funktioniert. Aber ich bin noch nicht soweit - es ist eben doch kein ganz kleines Projekt. Daher gebe ich Euch heute einen Zwischenbericht:

Ich habe das TGUItem nach unseren Vorgaben umgesetzt. Ein kleines Problem gibts noch (siehe dazu unten). Man sieht dem TGUIItem an, dass es eigentlich ein Leitungsnetz ist. Es hat aber auch grundsätzliche Eigenschaften (Name, Focus, ...) und Methoden (Hit,Shift,Draw,Load,Save), die alle seine Descendents brauchen.

Im Augenblick bin ich dabei, die Hilfsobjekte für das TGUIItem zu erstellen: den Themes-Manager (der hat schon ein paar nützliche Methoden für die Verwaltung von Farben und ein paar Zeichenroutinen erhalten) und den DataProvider (den gibts erst in einer gänzlich abstrakten Form).

Ich plane für nächste Woche:
* den GUI-Errorhandler implementieren
* Alle nötigen Supportfunktionen nachtragen: SDL/OpenGl-Fenster eröffnen, Textur und Schrift (ist nicht so wild wie es klingt, ich hab das schon zur Verfügung, muss es nur noch anpassen)
* TESTEN des GUIItems

Mehr lässt sich darüber nicht jetzt noch nicht sagen. Aber möchte ich Euch um Hilfe bitten, was die Umsetzung der Scripteinbindung in die Ereignishandler angeht. Ich schlage Folgendes vor, weiß aber nicht, ob das eine gute Methode ist. Von der Syntax her ist es richtig, der Compiler ist einverstanden:



Es geht mir hier nur um den "Script's eventhandler". Ist das OK?

Ich erwarte nicht, dass ich eine rasche Antwort kriege. Und ich bitte um Verständnis dafür, wenn ich auch nicht schnell antworte: heute wegen der ganzen Silvestervorbereitungen und morgen wegen des Restalkoholspiegels.

Ich wünsche Euch einen fröhlichen Rutsch ins neue Jahr und möget Ihr morgen von einem Brummschädel verschont bleiben!
Traude

Ich habe nun ein repo erstellt und brauche ledeglich noch accname und pwd von den jenigen die mit entwickeln wollen.
Die die einfach nur reingucken wollen, können das ohne authentifizierung tun.

http://www.linuxprofessionals.org/svn/dglgui/ WebSVN
svn://www.linuxprofessionals.org/dglgui SVN Repo

Wegen Acc einfach ne pm schicken ich trage das dann sofort ein.

Zum coden selber kann ich auch ein bischen was sagen.

Ich habe branch und trunk erstellt, wobei trunk die aktuelle version und branch die releases enthält.
sandbox ist ein Sandkasten zum spielen und austauschen.
Wenn ihr ein Code habt oder ähnliches, dann könnt ihr den dort rein werfen und mit anderen rum testen.
Wir brauchen noch eine Namenskonvention. Hier ein Beispiel, welches wir in XDream nutzten http://www.linuxprofessionals.org/svn/xdream/branches/0.2v/devdoc/codestyle.pas.

Eine Arbeitsaufteilung wäre auch nicht schlecht aber dafür ist erstmal ne liste der willigen Programmierer nötig.

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

Projekte: https://github.com/tak2004

Hallo,
jetzt kann ich mich ENDLICH zurückmelden. Ich habe in der Zwischenzeit die Dinge, über die wir uns einig waren, in Source Code umgesetzt. Es ist zwar nicht viel, aber der Rahmen steht und ich wollte zumindest was auf dem Bildschirm sehen können, bevor ich etwas herausrücke.

Im Anhang habe ich einen Delphi Source Code mit einer Minimalbeschreibung beigepackt, leider war die EXE zu groß, daher ist sie nicht dabei.

@Tak: ich melde mich als Programmierer an. Ich habe aber noch nichts zum SVN hinzugefügt, weil ich mit CVS/SVN bisher nicht gearbeitet habe. Könntest Du das machen?
Traude


@Edit: derzeit (13.37 Uhr) ist das SVN nicht erreichbar und DelphiGL übrigens auch nicht

Ich hab dein Zeug ins SVN gepackt.
Das SVN ist schon online aber das WebSVN ist verdammt schlecht.
Die SVN Web Module haben alle samt ein Problem, unszwar wollen sie root rechte und ich und der Administrator(kumpel) des Serverclusters wollen dies nicht als root laufen lassen. Wenn es nicht als root läuft kann er nach einem Comitt nicht mehr die Datenbank lesen, da er sie neu geschrieben hat und dem root den owner gegeben hat. Also hat er keine rechte mehr auf die Datei und so weiter.
Demnächst wollen wir WebDav rauf machen, denn dafür soll es ein workaround geben, welches dann keine root rights mehr bruacht.

Um mit dem SVN zu arbeiten kannst du dir unter Windows z.B. RapidSVN und Subversion laden oder Tortoise SVN.
Auf den Websites findet man dann die Anleitungen für die Software.

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

Projekte: https://github.com/tak2004

Da sich bis auf Traude keiner gemeldet hat sieh die Entwicklerliste so aus.

-Traude
-TAK2004

Immer hin einer mehr als beim DGL File Format Projekt.

Okey nun muss eine Code formatierung her.
Es werden auch Vorschläge von anderen Personen ausser Traude gerne gesehen.
Hier ist meiner http://www.linuxprofessionals.org/svn/dglgui/codestyle.pas.

@Traude ich wollte deine neue rev testen aber da fehlen ein paar Datein und er hat probleme existierende files zu laden.

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

Projekte: https://github.com/tak2004