QSA-interest Archive, August 2006
How to avoid wrapper when scripting a Qt application
Message 1 in thread
Hi,
Two or three years ago, I added QSA support in all my softwares with the
recommended method, i.e. wrappers containing only the slots and
properties I want to show to the end-user. I find this way of doing a
bit heavy to maintain and to develop. Furthermore, properties must be
defined both in the original application object and in the wrapper,
doubling the moc'ed functions and data.
Would it be possible to specify in the main class headers which slot and
which properties are to be exported to QSA?
For instance,
class Dummy : public QWidget
{
Q_OBJECT
Q_PROPERTY (QString prop1 READ prop1 WRITE setProp1 SCRIPTABLE true)
public:
Dummy( QWidget * parent = 0) : QWidget (parent) {}
...
virtual bool isScriptable() {return true;}
...
public slots:
Q_SCRIPTABLE void qsaSlot1();
... // public slots inside QSA environment (also public
in programmer env.)
void slot1();
// public slots inside programmer environment
...
};
In this object with the current QSA release, the user will see all
properties and slots of QWidget.
The SCRIPTABLE keyword is already available in Qt but poorly documented,
related to QMetaProperty::isScriptable(). Currently, the default is
"SCRIPTABLE true" for all properties. Switching the default to false,
then all properties of QWidget will disappear. Re-activating them could
be eventually done in custom classes that inherits QWidget
Q_SCRIPTABLE is currently already in Qt but not in the visible interface
and not used by moc.
Another aspect is the children query in QSA which uses the normal query
functions of QObject. To show only the scriptable children, I would
suggest to add a virtual function in QObject (I know always annoying to
modify such a basic object, but it does not increase QObject's size,
only its virtual table):
class QObject
{
public:
virtual bool isScriptable() {return false;}
};
If the programmer wants to set a class as scriptable just overload this
function
public:
virtual bool isScriptable() {return true;}
In QSA, there are only a few places where to check this condition when
extracting the list of children.
I patched Qt and QSA (including moc) and it works fine (not intensively
tested). The modifications are minimal and can be found on my ftp site
(ftp://ftp.geopsy.org/softwares/qt). But my main concern is whether or
not the main development stream will go or not in that direction. Is
SCRIPTABLE keyword added for new developments or is it an obsolete feature?
Thanks,
Marc
To unsubscribe - send "unsubscribe" in the subject to qsa-interest-request@xxxxxxxxxxxxx
Message 2 in thread
Hi,
I have used QSA a lot and can only strengthen the ideas of Marc. If
Wrapper-Objects can get avoided it would make the source more readable
and therefor would avoid bugs.
I am really interested to hear if things like that are planed for QSA
2.0. - Will we see QSA 2.0 this year?
Greetings
Jens
Marc Wathelet schrieb:
>
> Hi,
>
> Two or three years ago, I added QSA support in all my softwares with the
> recommended method, i.e. wrappers containing only the slots and
> properties I want to show to the end-user. I find this way of doing a
> bit heavy to maintain and to develop. Furthermore, properties must be
> defined both in the original application object and in the wrapper,
> doubling the moc'ed functions and data.
>
> Would it be possible to specify in the main class headers which slot and
> which properties are to be exported to QSA?
>
> For instance,
>
> class Dummy : public QWidget
> {
> Q_OBJECT
> Q_PROPERTY (QString prop1 READ prop1 WRITE setProp1 SCRIPTABLE true)
> public:
> Dummy( QWidget * parent = 0) : QWidget (parent) {}
> ...
> virtual bool isScriptable() {return true;}
> ...
> public slots:
> Q_SCRIPTABLE void qsaSlot1();
> ... // public slots inside QSA environment (also public in
> programmer env.)
> void slot1();
> // public slots inside programmer environment
> ...
> };
>
> In this object with the current QSA release, the user will see all
> properties and slots of QWidget.
>
> The SCRIPTABLE keyword is already available in Qt but poorly documented,
> related to QMetaProperty::isScriptable(). Currently, the default is
> "SCRIPTABLE true" for all properties. Switching the default to false,
> then all properties of QWidget will disappear. Re-activating them could
> be eventually done in custom classes that inherits QWidget
>
> Q_SCRIPTABLE is currently already in Qt but not in the visible interface
> and not used by moc.
>
> Another aspect is the children query in QSA which uses the normal query
> functions of QObject. To show only the scriptable children, I would
> suggest to add a virtual function in QObject (I know always annoying to
> modify such a basic object, but it does not increase QObject's size,
> only its virtual table):
>
> class QObject
> {
> public:
> virtual bool isScriptable() {return false;}
> };
>
> If the programmer wants to set a class as scriptable just overload this
> function
>
> public:
> virtual bool isScriptable() {return true;}
>
> In QSA, there are only a few places where to check this condition when
> extracting the list of children.
>
> I patched Qt and QSA (including moc) and it works fine (not intensively
> tested). The modifications are minimal and can be found on my ftp site
> (ftp://ftp.geopsy.org/softwares/qt). But my main concern is whether or
> not the main development stream will go or not in that direction. Is
> SCRIPTABLE keyword added for new developments or is it an obsolete feature?
>
> Thanks,
>
> Marc
>
> To unsubscribe - send "unsubscribe" in the subject to
> qsa-interest-request@xxxxxxxxxxxxx
>
>
To unsubscribe - send "unsubscribe" in the subject to qsa-interest-request@xxxxxxxxxxxxx
Message 3 in thread
Marc Wathelet wrote:
> Q_SCRIPTABLE is currently already in Qt but not in the visible interface
> and not used by moc.
The Q_SCRIPTABLE is respected by moc, it is just not respected for QSA.
I've made a task to fix this for the next patch release.
> Another aspect is the children query in QSA which uses the normal query
> functions of QObject. To show only the scriptable children, I would
> suggest to add a virtual function in QObject (I know always annoying to
> modify such a basic object, but it does not increase QObject's size,
> only its virtual table):
We consider adding support for this. A simple scriptable property in
QObject that you as the app developer can set. Would that suffice?
-
Best regards,
Gunnar
To unsubscribe - send "unsubscribe" in the subject to qsa-interest-request@xxxxxxxxxxxxx
Message 4 in thread
Gunnar Sletta wrote:
> Marc Wathelet wrote:
>
>> Q_SCRIPTABLE is currently already in Qt but not in the visible
>> interface and not used by moc.
>
> The Q_SCRIPTABLE is respected by moc, it is just not respected for QSA.
> I've made a task to fix this for the next patch release.
You're right, the only thing I had to modify in moc was the default
value of SCRIPTABLE for PROPERTIES (set to false rather than true).
>
>> Another aspect is the children query in QSA which uses the normal
>> query functions of QObject. To show only the scriptable children, I
>> would suggest to add a virtual function in QObject (I know always
>> annoying to modify such a basic object, but it does not increase
>> QObject's size, only its virtual table):
>
> We consider adding support for this. A simple scriptable property in
> QObject that you as the app developer can set. Would that suffice?
Do you meant to add a new member flag in QObject? That would be nicer
than a virtual function (as in my patch). At the time I wrote my last
message, I hadn't taken time to look into QObjectData where there is
still lot of space left for new flags (25), hence not increasing the
size of QObject.
Attached to this property, I guess you will add the necessary methods to
query "scriptable" children or parents. Unlike findChildren() that
returns all children recursively, I found it useful to have a function
that returns only the direct scriptable children (which might be not on
the same level as the usual children returned by children()).
Kind regards,
Marc
>
> -
> Best regards,
> Gunnar
>
> To unsubscribe - send "unsubscribe" in the subject to
> qsa-interest-request@xxxxxxxxxxxxx
To unsubscribe - send "unsubscribe" in the subject to qsa-interest-request@xxxxxxxxxxxxx
