Hallo,
ich habe mich in der Zwischenzeit umgesehen, was es an UML-Editoren gibt, das ist auch Neuland für mich. Kommt mir vor wie die uralten Ablaufdiagramme, die wir machen mussten, nur viel ausgefeilter und standardisiert. Ich werde mal das Grobkonzept in das Wiki-Pflichtenheft umarbeiten. Könnte sein, dass ich dabei die Überschriften manchmal ändern muss, weil das Pflichtenheft doch ziemlich auf die Beziehung Auftraggeber <-> Software-Unternehmen abzielt (lustigerweise ist keine Abteilung "Vertragspartner" vorgesehen, wobei das schliesslich immer das Interessanteste ist ).
Traude

Ich bins schon wieder.
Ich habe schon Schwierigkeiten beim zweiten Satz unter der Überschrift "Zielbestimmungen", da schreibe ich gerade:



Wenn ich jetzt schreibe: "Standard = Windows", werden alle schreien. Was also soll ich hier schreiben? Hier kann und soll man sich nicht mehr allgemein halten, hier soll man konkret werden, dazu ist schliesslich das Pflichtenheft da.

Wenn ich dich recht verstanden habe, meinst du damit den internen standard auf den die wrapper dann umleiten. Damit wäre zu dieser Stelle keine nötige konkretisierung nötig, da dies weiter unten im Pflichtenheft passiert.

Eine Platformfrage sollte so beantwortbar sein.
Für alle Platformen geeignet, wofür der Delphi und FreePascal compiler code compilieren können.

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

Projekte: https://github.com/tak2004

Nein ich meinte ganz einfach:

1) wie reagieren die Elemente(Knöpfe etc), wenn ich draufklicke: so wie in Windows/anders (ich frage, weil ich nicht weiss, ob Linux anders reagiert)

2) wie ist das sichtbare Erscheinungsbild der Elemente, welches "Look" wird ihnen verpasst: zB so wie WindowsXP/anders
Wenn Euch das nicht gefällt, gibts die Möglichkeit, als Standard für das GUI etwas eigenes zu definieren (das DGL-Blau zum Beispiel)

Achso, na dann.
Jo wie Windows, denn das ist das beste Kontrol was ich kenne.
Linux und Windows nehmen sich nicht als so viel vom Handling.

Vom aussehen ist das natürlich ganz anders, denn Gnome und KDE besitzten Scriptsprachen zum zeichnen von Elementen.
Damit kann ein Button rund, eckig oder sonnst wie aussehen.

Das finde ich aber ziemlich blöd, da es alles langsamer macht, der wiedererkennungseffekt verschwindet und es den Code extrem aufbläht.

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

Projekte: https://github.com/tak2004

OK ich schreib fürs Aussehn mal "wie Windows" und für die GUI-Reaktionen "Allgemeiner Standard".
Traude

Ich habe das Pflichtenheft mal mit dem ausgefüllt, was ich weiß.
Es fehlt noch:
-- beim Punkt "Produktübersicht" das Diagramm
-- beim Punkt "Qualitätsanforderungen" die Anforderungstabelle

Vielleicht könnt Ihr Euch das mal ansehen: http://wiki.delphigl.com/index.php/DGLGUI_Pflichtenheft






Nachtrag: ich habe die Produktübersicht und die Qualitätsanforderungstabelle ergänzt. Mein Diagramm zur Produktübersicht ist nicht sehr professionell, ich kann leider nicht UML, und die Zeit war zu knapp, um es zu lernen.
Traude

Traude war ja richtig fleißig aber du solltest das diagram mal in einer größeren version hochladen, da es nicht lesbar ist.

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

Projekte: https://github.com/tak2004

Ich habe das Diagramm jetzt größer gemacht.

Übrigens: Jemand hat bei der "technischen Produktumgebung" den Punkt "OpenGL 1.1 Unterstützung (Verwendung von Texturen)" eingefügt, was grundsätzlich stimmt: ohne Schriften ist kein sinnvoller Betrieb der GUI möglich, und alle Schriften, die ich kenne, brauchen eine Textur.

Aber sollten wir da nicht allgemeiner schreiben: "Grafikbibliothek mit Texturunterstützung" ?

Außerdem fehlt dann hier ja auch noch: "Betriebsystemspezifische Funktionen zum Entgegennehmen der Benutzereingaben", das trage ich noch nach.


* Hüstel * ist Euch das Pflichtenheft ausführlich genug?

Wenn ja, dann könnten wir uns doch wieder den technischen Dingen zuwenden, wie das Wikipedia so schön sagt: der technischen Spezifikation?
Traude

Ich werde das bisherige Grobkonzept als Grundlage für eine technische Spezifikation nehmen und es als Anhang zum Pflichtenheft ins Wiki stellen.
Traude

Ich hätte es gerne ausführlicher, wenn möglich mit Beispielen wie was funktionieren sollte.

Ach, und wo wurde gesagt, dass das Theme der GUI zu Laufzeit wechselbar sein sollte?

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

Du möchtest das also nicht haben? Dann nehme ich es wieder raus


Aber Scherz beiseite: Es ist so, wenn man das mit Beispielen untermalt, dann geht es ins programm-technische Zeug hinein. Und eigentlich sollte so etwas nicht im Pflichtenheft stehen, sondern gehört in die technische Spezifikation. Das GUI hat eine Sonderstellung, weil es ein Programmteil ist, daher ist der Programmierer hier ein Benutzer. Also, ich würde sagen, sucht es Euch aus. Entweder ich hänge, wie oben gesagt, ans Pflichtenheft einen Anhang "Technisches Konzept" dran, oder ich arbeite die genauere Beschreibung, die ja ein programmtechnischer Teil sein muss, ins Pflichtenheft ein.
Traude

Habe ich gerade gemacht
Ist jetzt ein optionales Feature.

Ich hab gerade noch ein paar Kleinigkeiten überarbeitet.

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

Das habe ich gesehen, aber warum hast Du es rausgenommen? Eigentlich müssen Texturen ohnehin dabei sein, sonst geht keine Schrift. Und da war dann auch die Rede davon, dass man gleich ein Standard-Theme haben könnte. Hat auch keiner wiedersprochen, drum habe ich es mal so hineingenommen.
Traude

Mir geht es um den Begriff "Laufzeit" in dem Satz. Das würde bedeuten das der User bei der Binary dann nen Skin wählen könnte und wir als GUI dann dafür sorgen dass alle Komponenten von dem neuen Skin erfahren.
Da würde ich aber sagen, dass dies kein Muss-Feature ist und es der Programmierer ohne weiteres erstmal selbst implementieren könnte.

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