[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: [RFC] Unified Application Scripting Interface
From:       Neil Stevens <neil () qualityassistant ! com>
Date:       2001-11-12 23:36:48
[Download RAW message or body]

On Monday November 12, 2001 03:20, ian reinhart geiser wrote:
> The idea is that the script engine runs the script.  The control from
> the main application comes from the *parent via an object twin or via
> dcop.
>
> - From python/shell/perl one has access to the dcop interfaces.  From
> python via an object twin you have full access to public members of the
> parent pointer.
> Again this is completely based on the script engine.  You seem very hung
> up on this dcop thing,  it really is not that radical of a jump.  We are
> just moving a dcop script from the external of an application to be
> controlled by the application itself.  I guess I fail to see an example
> where the

*There* we go.  Thank you.

OK, I see now, however I make one suggestion: instead of making the parent 
a plain QObject, make it some special KScriptParent or something:

class KScriptParent : public QObject
{
// ...

public slots:
	// Send a command to the app with an arbitary number of arguments
	// Returns any answer the app sees fit to provide
	virtual QValueList<QVariant> command(QString, QValueList<QVariant>) = 0;
	// Send a command to the app with no arguments, overloaded for convenience
	QValueList<QVariant> command(QString);
};

I think this would go a long way toward making the system an easy and 
powerful way of making applications scriptable.  And, the more standard 
commands you define, the better.

-- 
Neil Stevens
neil@qualityassistant.com

Don't think of a bug as a problem.  Think of it as a call to action.

[prev in list] [next in list] [prev in thread] [next in thread]