Zitat:

---

Das ist nicht kompliziert. Der erste Schritt besteht in der Aufteilung von Attributen in mehrere Objekte, wie Du sie selbst schon angedeutet hast.

---

Zitat:

---

Zitat:

---

Wie soll man denn GUI-Klassen anlegen, denen man keine Position und Größe geben kann, da muss man ja einen Layoutmechanismus bauen, dem man sagen kann, hier haste ne Komponente, mach sie mal in der und der Größe da und da hin, oder?

---

Das gibts dann schon, aber wie gesagt, man kann an den überladenen Methoden sparen. Und da das Programm weiß, wann es layouten muß, könnten die Layout-Manager auch direkt in die bounds schreiben und danach die zugehörigen set() Methoden auf den Gadgets aufgerufen werden (für Boopsi). Im Falle von OS1.x-gadget-Strukturen werden die Gadgets einfach komplett während des Layouts-Prozeß ausgehängt und danach wieder eingehängt. Das ist fast das einzige Mal, daß man das überhaupt braucht.

---

Zitat:

---

Normalerweise kennen Bilder selbst schon ihre Größe. Und dann gibt es minimum, preferred und maximum size (i.A. read-only).

---

Zitat:

---

Ja, aber auf plain Gadgets zu setzen, bedeutet schon Mehraufwand für Dich. ReAction und MUI bieten von Hause aus schon eine Menge, das Du noch implementieren müßtest.
Es sollte eigentlich auch gar nicht so schwer sein, die Klassen so zu entwerfen, daß ein Wechsel zwischen MUI und ReAction möglich ist.

---

Das stimmt auch wieder, nur habe ich bisher noch nie mit MUI und ReAction gearbeitet, da ich möglichst ohne 3rd Party Software auskommen wollte und das Framework auch nur für den heimgebrauch sein soll (wobei ich dann schon ne möglichst flexible Sache machen wollt, die auch vom Design her stimmt ).

Wo bzw. wie kann man denn gutes Design usw. lernen? Denn damit hab ich immer wieder Probleme, trotz jahrelanger Programmiererfahrung!

Ciao

Zitat:

---

Original von Holger:


Richtig gemacht, ist der Aufwand nicht höher als die Definition einer enum, spricht im Endeffekt eine Zeile pro Konstante plus einem konstanten Aufwand für den Rahmen.

---

Zitat:

---

Das geht ja dann in die Delegation-Richtung. Eine solche Attributklasse für bestimmte Flags entspricht der Flags-Klasse, wie ich sie meinte. Und ausgelagerte Attributklassen für den eigentlichen Inhalt einer Komponente, dem Text eines Label oder eines StringGadgets, Range und Position eines ScrollBars entsprechen den Datenmodellen.

---

Zitat:

---

Zitat:

---

Wenn Du magst, kann ich Dir ja mal die Hierarchie schicken, sobald sie angelegt ist.

---

Gerne.

---

Mach ich gern, wird aber noch ne ganze Weile dauern, da ich nur selten zum Programmieren komme. Dann wirds auch nur die Klassen enthalten, welche ich z.Z. selber benötige.
Das Framework soll ja eigentlich kein öffentliches werden, sondern nur mir jetzt und in Zukunft die Programmierung das Amiga API erleichtern und mir C++ näher bringen.
Letzteres scheint gar nicht so gut zu klappen, mach glaub immer noch eher Java-Stil!

Ciao

Zitat:

---

Also SetGadgetAttr dient zur Manipulation von BOOPSI-Objekten, einschließlich Datatypes und ReAction. Für "GadgetStrukturen" dienen sie nicht.
Also entweder Du benutzt immer BOOPSI, dann wrapst Du nur einen Pointer und darfst nie etwas anderes benutzen als SetGadgetAttr(...), oder Du wrapst eine GadgetStruktur im OS1.x-OS3.x Sinn, dann darfst Du SetGadgetAttrs gar nicht benutzen.

Ich habe es vielleicht noch nicht deutlich genug gesagt, meine Empfehlung lautet für Position und Größe, sie überhaupt nicht manipulierbar zu machen. Die sollten über einen Layout-Mechanismus kontrolliert werden, der im Endeffekt nur von der Fenstergröße abhängt.
Das erwartet man eigentlich seit OS2.0 von ordentliche Programmen.

---

Zitat:

---

Mhh, also
button.setRelverify(true);
oder
button.setFlags(button.getFlags()|RELVERIFY);
oder
button.flags|=RELVERIFY;

Mit gefällt schon die letztere Variante besser.

Der Name des Flags taucht trotzdem in allen Varianten auf.

Zitat:

---

Bei "sprechenden Settern" entfällt das wenigstens zum Teil.

---

"Sprechende" Flag-Klassen bieten das auch. Lieber mehrere kleine Klassen als eine Mammut-Klasse. JComponent sollte doch ein gutes abschreckendes Negativ-Beispiel sein. (Von einigen seiner Unterklassen gar nicht zu reden)

---

Zitat:

---

Original von Holger:

Zitat:

---

Natürlich, aber darum geht es ja gar nicht. Du wolltest die Tatsache, daß ein Objekt in einem anderen enthalten is, bzw. den InUse-Zustand als interface umsetzen. Das ist aber technisch unmöglich. Die containment und inUse-Eigenschaften ändern sich zur Laufzeit. Das Objekt, bzw. die zugehörige Klasse kann aber nicht plötzlich die implementierten interfaces ändern, weder in Java, noch in C++.

---

Nicht ganze, ich wollte, dass die Klassen, für welche das InUse in Frage käme das entsprechende Interface implementieren und daher gezwungen sind, eine InUse-Auswertung zu machen.

Zitat:

---

war noch unter Java1.3.1, jetzt gibts ja auch Templates

---

Templates und Generics sind völlig unterschiedliche Dinge. Sollte man auf keinen Fall in einen Topf werfen.

---

Zitat:

---

In C++ kann man das noch mit dem Operator-Overloading vereinfachen. Wenn die Attribute Klassen mit angepaßtem Zuweisungsoperator sind, kann man sie als public-Instanzvariablen anlegen, auf die eine einfache Zuweisung statt Methodenaufruf durchgeführt werden kann.

In der Form:
class Button {
public:
Attr<String> label;
}
//...
button.label="Hallo";

Wenn der Attr-Zuweisungsoperator dann die SetGagetAttr-Funktion aufruft...
Ich glaube, so etwas in der Form hatten wir schon in der Mailkorrespondenz. Müßte ich mal nachschauen. Ich habe damit mal im Zusammenhang mit MUI rumgespielt, weiß jetzt gerade nicht, wie der Stand der sourcen war.

---

Wenn das die Mails sind, die ich auch gerad im Kopf hab, da gings um die Typisierung von TAGITEMS, danke nochmal dafür!
Obiges bedeutet, ich muss den Zuweisungsoperator der Klasse Attr für unterschiedliche Typen unterschiedlich gestalten?!
Also ein

Attr<String>...="Hallo";

wird anders behandelt als ein

Attr<int>...=10;

?
Mit Operatorenüberladung hab ich mich bisher noch nicht beschäftigt, davor schrecke ich zurück, das liegt mir gar nicht. Da weiss man nicht mehr, was ein = macht und ein + !

Also wenn ich Dich recht verstanden habe, muss ich bei den Wrappern für struct Gadget und den daraus resultierenden Klassen darauf achten, dass die setGadgetAttr-funktionen verwendet werden, v.a. wenn die Gadgets schon Verwendung finden.
Die Wrapperklassen für struct screen und struct window müssen wiederum andere Dinge berücksichtigen, wenn sie Setter für Attribute (oder überladene Operatoren) anbieten.

Denke mal z.B., dass wenn man in C ne Imagestruktur mit Dimensionen füllt, die nicht zu den Bilddaten passen wird Müll dargestellt. So was will ich nach Möglichkeit verhindern!

BTW: Gibst Du auch Kurse in C++, operator overloading, Delegation, Patterns (Letztere beiden kenne ich zwar, hab sie aber seltenst verwendet)?

[ Dieser Beitrag wurde von Reth am 06.12.2005 um 16:11 Uhr editiert. ]

Zitat:

---

Original von Holger:

Zitat:

---

Da ein Image auch eingebettet (z.B. in meiner Klasse ImageButtonC) verwendet werden kann, brauch ich noch ne gute Idee, wie ich das inUse-Flag setze.

---

Da Bilder auch in mehr als einem Objekt stecken können, bräuchtest Du schon einen counter. Aber wie schon gesagt, ich habe so meine Zweifel an der Sinnhaftigkeit dieses Trackings.

---

Zitat:

---

Das glaube ich nicht. Ob eine Klasse ein bestimmtes interface erfüllt, wird zur compile-Zeit festgelegt. Welche relevante Information soll Dir das zur Laufzeit bringen?

---

Zitat:

---

In Java trägt sich die Komponente entweder als image-consumer ein und erfährt, wenn sich etwas ändert, oder sie geht von immutable images aus, und der Anwendungsprogrammierer muß sich selbst um Thread-Synchronisation kümmern.
Ähnlichkeiten sehe ich da nicht.

---

Zitat:

---

Original von Eule:
@Reth:

Könntest du einen Schatten hinzufügen ? Deine Bäume haben jedenfalls einen.

Ich vermute mal dass du die Türme einfach in des Feld einstanzt ohne Tranparenz o.ä.

---

Zitat:

---

Original von Eule:
@Reth:

Na ja das Spielfeld ist von oben, die Türme von der Seite ... wären die Türme etwas 'isometrischer' dann würden sie räumlicher aussehen und besser auf so eine Landkarte passen.

Theoretisch ( und jetzt verlang ich warscheinlich zu viel von dir ) könnte man die 6 eckigen Felder stauchen. Falls die Türme und die Landschaft der selben isometrischen Projektion entsprächen, wäre das Ergebnis perfekt.

---

Zitat:

---

Original von Eule:
@Reth:

Sieht doch ganz nett aus aber die Grafik der Türme sollten man vielleicht noch etwas ändern.

---