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

[Elvis Stansvik]

2011/7/11 Andreas Vox <andreas.vox at googlemail.com>:
>
> Am 11.07.2011 um 18:19 schrieb 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.
>>
>
> Since PageItem already is a QObject and PageItem is (or should be) the superclass
> of PageItem_Table, PageItem_Table should be a QObject, too.

Doh! Didn't even look before firing off that mail and assumed PageItem
was not a QObject. Sloppy ;)

>> 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?
>
> Yes, all PageItems should be proper QObjects to be scriptable.

Great.

Elvis