Argh, und ich hab bisher gedacht, du hättest deine Daten in verschiedene übereinander gelegte Schichten gepackt, um irgend welche speziellen Optimierungen umzusetzen.
Äh, nein. Das Schichtenmodell dient allein einer besseren Struktur. Daneben werden die Schichten nicht im Vorherein festgelegt, sondern ergeben sich teilweise auch aus der Aufrufreihenfolge und den Abhängigkeiten. Es soll aber natürlich darauf geachtet werden, dass Low-Level-Klassen (mathematische Vektoren, spezielle Arrays etc.) ganz unten liegen, die geometrischen Objekte z.B. eine Schicht darüber, da sie nicht nur Daten halten, sondern auch auswerten, und die GUI muss mit dem Viewer irgendwo ganz oben liegen, da sie die Schnittstelle zum Endbenutzer sind.
Zum besseren Verständnis zeichne ich mal ein kleines Bildchen (siehe unten), wie der aktuelle Zustand ist. Wie Du siehst, ist das schon schichtenähnlich (Zugriffe nach oben habe ich nicht dargestellt), aber von MVC kann man nicht reden.
Zur Erklärung: Das geometrische Objekt hält die Selektion (Anzahl diskreter Punkt = Größe des Booleschen Arrays), das Szenenobjekt selektiert aber. Diese Daten, welcher Punkt selektiert/deselektiert wurde, muss an den Viewer gereicht werden.
Ich bin nach Deinem letzten Posting unsicher, was nun der bessere Ansatz ist. Ein Array vom Viewer nach unten geben, damit es vom Szenenobjekt befüllt wird. Oder alles ab und oberhalb des Szenenobjektes von QObject ableiten und per Signal nach oben geben. (Hinweis: Das Bild ist immer noch vereinfacht. Die ganzen Listen-Klassen, die Objekte halten, habe ich nicht eingezeichnet. Der Weg nahc oben wird also länger.)
Wobei es darauf ankommt, in wieweit Scene ein Wrapper um "Geometrische Daten" ist. Ist "Geometrische Daten" eine eigene Klasse/Struktur, oder hält die Szene die Daten?
Das Bild macht es hoffentlich klar. GeoDaten ist ein Objekt, Szenenobjekt ist ein Wrapper, Szene enthält viele Szenenobjekte.
Aber im Prinzip ist das genau die Anordnung die du für ein Qt Model/View hast
Da ist bei uns die Konstellation wieder unglücklich. Ich entwickle nämlich derzeit mit Qt 3.3.8. Wenn ich fertig mit kapseln bin, portiere ich auf Qt 4.5.2 mithilfe von qt3to4. Aber ich werde danach keine Umstrukturierungen mehr vornehmen. (Die Idee war, dass der Aufwand so geringer ist, weil man die gekapselten Pakete/Module einfacher nach Qt4 wandeln kann, als erst das ganze große Projekt.)
Heißt Header Dateien ins Projekt kopieren, fertig
Und danach zig Formulare ausfüllen, um die Erlaubnis zur Benutzung einzuholen.
(Nein, nicht die Erlaubnis der Boost-Entwickler ...)
Aber ich hab mal reingeschaut und es sieht schon interessant aus. Privat werde ich darauf ggf. mal zurückgreifen.
Viele Grüße
Dee
Aber mal schauen ...