Anzeige:
Ergebnis 1 bis 8 von 8

Thema: [Qt4.2] Aktionen mit QGraphicsItem

  1. #1
    Registrierter Benutzer
    Registriert seit
    31.08.2002
    Ort
    Berlin
    Beiträge
    128

    [Qt4.2] Aktionen mit QGraphicsItem

    Hi,

    vorneweg ich arbeite mit der Qt4.2 tp1 Version. Ich habe jetzt mehrere QGraphicsItems auf mein QGraphicsView erstellt. (Ellipse, Kreise, Rechtecke und was es so alles gibt)
    Nun such ich eine Idee womit ich am besten diese Objekte verändern kann. Also z.B. die Größe verändern, verschieben, Füllen der Objekte usw. also so gut wie alles was das Aussehen der Objekte angeht soll der User auch später verändern können.
    Nun wie mach ich das am Besten ohne viel Aufwand?

    Meine Idee sieht zur Zeit folgender Weise aus:
    Ich erstelle jeweils eine eigene Klasse abgeleitet von den QGraphicsLineItem etc. hinterlege jede Eigenschaft des Objektes in meine eigene Property Klasse und muss dann jeweils die Eigenschaften setzen beim Zeichnen des Objektes und die Eigenschaften wieder lesen um ein Menü für den Benutzer zu erzeugen.

    Nur müsste ich dann jede QGraphics Klasse eine eigene Klasse erzeugen und alle Methoden zum Setzen und holen der Eigenschaften händisch überschreiben damit ich auf das QGraphics Klassen transparent benutzen kann.
    Wie wird das den z.B. im QtDesigner berwerkstellig das man die Eigenschaften der Objekte so leicht verändern kann?

    Gruss,
    xmarvel

  2. #2
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Zur Frage wie das Designer macht:
    http://doc.trolltech.com/4.1/properties.html

    Die Widgetklassen haben entsprechende Properties deklariert und Designer kann diese abfragen.

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  3. #3
    Registrierter Benutzer
    Registriert seit
    31.08.2002
    Ort
    Berlin
    Beiträge
    128
    hi anda_skoa,

    hab mir das mal durchgelesen und die setzen ja ziemlich stark auf Macro diesbezüglich. Da das ziemlich kompliziert aussieht muss muss ich doch mir jede Klasse ableiten.
    Ich überlege mir mal wie die Klassen definitionen später aussehen könnten und meld mich dann nochmal.

    Gruss,
    xmarvel

  4. #4
    Registrierter Benutzer
    Registriert seit
    31.08.2002
    Ort
    Berlin
    Beiträge
    128

    Lightbulb Idee 1

    so hab mir mal die Klassen Definitionen so wie ich mir das zur Zeit vorstelle geschrieben bitte schaut es euch mal an und schreibt eure Meinungen, Kritiken dazu.

    die Property Klasse wo die Eigenschaften abgespeichert werden:
    Code:
    class Property
    {
    	enum Type {Path, List}; // speziele Wert Typen
    	
    	public:
    		void insert(const QString& name, const QString& label, const QVariant& value);
    		
    		QString name(int); // ID für die xml Datei
    		QString label(int); // Angezeigter Name
    		QVariant value(int); // Wert der Eigenschaft
    
    		bool isVisible(int);
    		bool hasReset(int);
    
    		int indexOf(const QString&);
    		int count() const;
    		Type type();
    		
    		void setVisible(int, bool);
    		void setValue(int, const QVariant);
    		void reset(int, bool); // Setzt den Wert zurück
    
    	private:
    		struct PropertyItem
    		{
    			QString name;
    			QString label;
    			QVariant value;
    			QVariant defaultValue;
    			
    			bool visible;
    		};
    		
    		QMap <int, PropertyItem> m_properties;
    };
    Die generelle Graphic Item Klasse wo jedes Grafik Klasse von abgeleitet wird.
    Code:
    class GraphicItem : public QGraphicsItem
    {
    	public:
    		~GraphicItem();
    		virtual void propertyInit() = 0;
    		virtual void propertyChange(const QString&, const QVariant&) = 0;
    		
    		inline Property* property() { return &m_property; };
    		
    	private:
    		Property m_property;
    };
    und hier als beispiel dann mal eine Graphik Klasse müsste ich dann für jede einzelne Graphik Klasse dann machen
    Code:
    class GraphicLine : public QGraphicsLineItem, GraphicItem
    {
    	public:
    		inline void propertyInit()
    		{
    			property()->insert("pos", "Position", QPoint(20, 20));
    			property()->insert("size", "Größe", QSize(200, 200));
    			// usw.
    		}
    		
    		inline void propertyChange(cosnt QString& name, const QVariant& value)
    		{
    			int id;
    			id = property()->indexOf(name);
    			
    			property->setValue(id, value);
    		}
    };
    Danke schnomal fürs Anschauen.

    Gruss,
    xmarvel

  5. #5
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Das sieht nach einer doppelten Ableitung von QGraphicsItem aus.

    Vielleicht eher mit einer Zusatzklasse. in etwa so

    Code:
    class PropertyItem
    {
    public:
        PropertyItem(QGraphicsItem* item) : m_item(item);
    
        // deine property methode, usw
    
        void applyProperties();
    
    protected:
       QGraphicsItem* m_item;
    
    protected:
        virtual void applyProperty(int);
    };
    Die Basisimplementation von applyProperties kann dann schon mal alle Werte handhaben, die für alle GraphicsItems gleich sind.
    Abgeleitete Klassen können dann für speziellen Typen von QGraphicsItem noch andere Werte machen.

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  6. #6
    Registrierter Benutzer
    Registriert seit
    31.08.2002
    Ort
    Berlin
    Beiträge
    128
    hi anda_skoa,

    ich verstehe dein Konstruktor nicht wie behebt er das Problem mit der doppelten Ableitung?
    Wäre nett wenn du ansatzweise die Klassen Definition eine Graphik Klasse schreibst z.B. GraphicLine.

    Gruss,
    xmarvel

  7. #7
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Man hat eine separate Hierachie, also PropertyItem als Basis, PropertyLineItem für QGraphicsLineItem, usw

    PropertyItem bzw sein Subklassen sind praktisch eine zusätzliche API zu den GraphicsItems

    Man setzt von außen Properties und bei applyPropeties wird dann der aktuelle Zustand auf das GraphicsItem übertragen

    Alternativ kann man auch bei der Änderung eines Properties gleich die entsprechende Änderung am GraphicsItem durchführen.

    Also am Beispiel Line:

    Code:
    class PropertyLineItem : public PropertyItem
    {
    public:
        PropertyLineItem(QGraphicsLineItem* line) : PropertyItem(line) {}
    
    protected:
        void applyProperty(int index)
        {
            QString name = m_properties[index];
            if (name == "line")
            {
                static_cast<QGraphicsLineItem>(m_item)->setLine(m_properties[index].value().toLine());
                return;
            }
    
            // fall through to base
            PropertyItem::applyProperty(index);
        }
    };
    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  8. #8
    Registrierter Benutzer
    Registriert seit
    31.08.2002
    Ort
    Berlin
    Beiträge
    128
    Das ist ja ein ganz anderes Konzept.

    Der Vorteil ist natürlich man braucht die GraphicItems nicht ableiten aber dafür halt die Properties.
    Aber was mich dabei stört ist die Beziehung zwischen Properties und GraphicItems.
    Denn das einzelne GraphicItem weiss zur ganzen Zeit nicht an welchen Property Objekt er dran hängt.
    Nur das Property Element weiss welches GraphicItem er zur Zeit bedient hat.

    Aber später im Programm ist es doch logischer wenn man ein QGraphicItem (z.b. QGraphicLineItem) anklickt und vom ihm seine Properties holt und nicht die PropertyItems abfragt welches denn gerade angeklickt wurde.

    Später sollen auch eigene QGraphicItems entstehen dann bräuchte man dann gleich zwei Klassen jeweils das GraphicItemUser und dann das PropertyItemUser welche das andere "steuert".

    Aber schon mal ein sehr guter Gedanken Anstoss vielleicht kann man ja ein mittelding daraus schaffen.

    Gruss,
    xmarvel

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •