[scribus-dev] Tables GSoC - Weekly Report #6

[Elvis Stansvik]

2011/7/11 Elvis Stansvik <elvstone at gmail.com>:
> 2011/7/11 Andreas Vox <andreas.vox at googlemail.com>:
>> Hi Elvis!
>>
>> Yes, listening to the StyleContext is the way to go.
>> For listening to an Observable you can just derive from this class and
>> implement ist changed() method:
>>
>> // in observabe.h:
>>
>> template<class OBSERVED>
>> class SCRIBUS_API Observer {
>> public:
>>        virtual void changed(OBSERVED) = 0;
>>        virtual ~Observer() {}
>> };
>>
>> or you use
>>      bool Observable::connectObserver(QObject* o, const char* slot);
>>        bool Observable::disconnectObserver(QObject* o, const char* slot =
>> 0);
>>
>> to connect an Observable to an QObject-observer; in that case deriving from
>> QObject is enough.
>> The Observable::update() method will notify both kinds of observers.
>
> Ah. Great. Thanks.

..and considering PageItem_Table is neither a QObject nor an Observer
ATM the natural follow-up question is of course; which route do I
take?

I guess it probably makes sense to make it a QObject? I see that e.g.
StoryText is a QObject and uses the Observable<->QObject approach for
observing style changes.

At the moment the PageItem_Table simply has setters/getters for its
properties, these set/get the properties on the underlying locally
stored style. There are no "reset" functions yet, but these will
probably have to be written, so that properties can be reset to be
inherited from the named style.

The reason I say think making it a QObject makes sense is partly the
new scripter, and partly the UI in the PP.

The current "bare" setters/getters on PageItem_Table could then be
declared as Qt properties with Q_PROPERTY. E.g.

Q_PROPERTY(qreal leftBorder READ leftBorder WRITE setLeftBorder RESET
resetLeftBorder NOTIFY changed)

and then in addition to emitting PageItem_Table::changed() when one of
the setters is called, the PageItem_Table would emit it if a table
style changed (by observing them using the Observable<->QObject hookup
mechanism).

And the UI in the "Table" palette in the PP could then connect to
PageItem_Table::changed() to know when to update its controls.

And by making them proper Qt properties, perhaps it will not be
necessary to make a separate wrapper class for the new scripter to
work with?

Does this make sense?

Elvis