Das mündete dann in eine Schnittstelle für alle grafischen Objekte:

class visual_object {
    virtual void mouseClick( ... );
    virtual void bbox( rect& );
    virtual void changed_bbox( rect& );
    virutal void draw( ... );

    virtual event get_prechange_event() const;
    virtual event get_changed_event() const;

    ....
};

Das ganze delegiert also passend etwaige Events "nach unten" und der View hört den Objekten im Gegenzug zu, ob sie sich verändern und versucht das Neuzeichen dann einigermaßen effizient zu gestalten. So weit so gut. Von dieser Klasse habe ich dann einiges abgelitten unter anderem natürlich auch:

class visual_node : public visual_object;
class visual_edge : public visual_object;

Bisher hatte ich nicht vorgesehen, dass visual_object Kinder haben können (also Teil einer Hierarchie). Nun hatte ich aber den Gedanken, dass in einem gerichteten Graphen eigentlich der Quellenknoten einer Kante für diese Kante zuständig sein sollte. Also machte ich mich erstmal daran, einer Container-Klasse zu basteln, die alle Events "von oben und unten" (in der Hierarchie) entsprechend weiterleitet, was auch super funktioniert.

class visual_container : public visual_object {
public:
     addChild( boost::shared_ptr<visual_object> child );
     ...
};

Funktionierte einigermaßen gut, ich konnte direkt aus der Viewklasse einiges rausnehmen und dort sozusagen nur noch ein "Desktop"-Objekt (Also eine Wurzel) speichern und direkt alle events einfach in mein Format konvertieren und dann delegieren.
Aber nachdem ich das getan habe, ist mir aufgefallen, dass ich mein Problem damit überhaupt nicht gelöst hatte. Denn soetwas wie

class visual_node : public visual_container {
};

funktioniert jetzt nicht, da visual_node dann seines Teils eigentlich gar kein eigentständiges visual_object mehr ist.
Im Prinzip müsste der Knoten jetzt eigentlich (zumindest meinem Design entsprechend) eher ein Kind von dem visual_container sein, damit das mit dem Event-Routing einigermaßen klappt, aber dann wäre er wiederum nicht mehr "zuständig" für die visual_edge's.
Also im Prinzip bräuchte ich eine Möglichkeit, wie der visual_container Aufrufe an die visual_object-Schnittstelle abfangen kann und nur unter bestimmten Umständen an die Implementation der Schnittstelle von dem visual_node (der in diesem Fall wie oben beschrieben von visual_container abgeleitet ist) weiterleitet.
Die einzige Lösung, die mir da adhoc einfällt, wäre, dass der visual_container das visual_object-Interface unter anderem Namen repliziert und der visual_node dann dieses Interface implementiert. Aber das gefällt mir einfach nicht, weil es dann einen Unterschied für die Implementierung der einzelnen Klassen macht, ob sie Kinder haben können oder nicht.
Andererseits könnte ich einfach jede Klasse von visual_container ableiten, aber ich habe dann Angst dass mir das in weiteren Fällen des gleichen Problems dann genauso geht und ich am Ende ein riesiges Interface für jedes Objekt habe.

Ich hoffe es findet sich jemand, der sich die Zeit nimmt, diese Textwand zu überfliegen und mir evtl. hilfreiche Ratschläge geben kann, ob und wie man das besser lösen könnte. Vielen Dank schon einmal für eure Zeit.

MfG
Michael

ohne jetzt sehr detailliert in Dein Klassendesign und die damit verbundenen Probleme einsteigen zu wollen: schau Dir bitte einmal das Kompositum-Entwurfsmuster an: http://de.wikipedia.org/wiki/Kompositum_(Entwurfsmuster)

Gruß
Stephan

Michael