[Qt-creator] Extending Qt Creator with scripts

[eike.ziller at nokia.com]

On 1 Nov 2011, at 22:45, ext Nicolas Arnaud-Cormos wrote:

> Thanks for the feedbacks, see comments inline.
> 
> On Monday 31 October 2011 10:49:38 eike.ziller at nokia.com wrote:
>> Hi,
>> a few random thoughts from my side on this:
>> 
>> ECMA Script / JavaScript would probably be a sensible language to use, both
>> because of support in Qt, and it's also quite widely used. [...]
> 
> Ok, seems like we have a consensus on the scripting langage, let's go for 
> Javascript. I don't know what Qt5 will be, but at least we have support in Qt 
> 4.

Will be in "done" state in Qt5, i.e. get P0 fixes (security etc) but otherwise frozen.
The V8 engine was supposed to get similar integration features, don't know the state of that, but is in the not-so-near future anyhow.

>> Separating the script interface from the C++ interface might work out, if
>> we follow a mindset of "only very specific api that we deem most useful is
>> exposed through script". It wouldn't be maintainable otherwise. We once
>> had the idea of "expose all API through script", but stopped trying very
>> soon afterwards ;). Even though there is one or the other QtScript
>> bindings generator out there, which might make some things easier. 
> 
> I honestly don't think we should use a binding generator. The goal is to make 
> things fast and easy, even if not as powerfull as the C++ API.
> I'm more in the "only very specific api that we deem most useful is exposed 
> through script" mood.
> Another issue is that the script would be too sensible to any API changes. If 
> we have a script interface, we could at least provide compatibility.
> Also, exposing everything could give a bit too much power, with the 
> possibility of mis-uses.
> 
>> [...] We'd need
>> to provide separate documentation about the script interface to the user,
>> if we create a separate, manual one.
> 
> Indeed, documentation must be written. But if we want to do a script 
> interface, we need to write some kind of user documentation at some point, 
> maybe a bit easier than the API documentation.
> 
>> Maybe an approach more like what is done by the Squish GUI testing
>> framework would be more feasible? They are using object names (& object
>> types?) & the QObject parent hierarchy to find an object, and then use the
>> meta object to call Q_INVOKABLEs and slots on them. ---> No need to
>> maintain a separate API or generate additional code for it (except for
>> making useful things invokable and making objects findable). Would
>> certainly be interesting to investigate IMO.
> 
> I'm not certain it's the best approach, but maybe the two can be available: 
> provide a simple script interface for basic use cases, and a also using object 
> name and hierarchy for more complex use cases.
> 
> On Monday 31 October 2011 10:09:21 bill.king at nokia.com wrote:
>> I've also been considering a script runner plugin in my capacity as QA for
>> creator. I would rather have as much surfacing as possible done inside the
>> one plugin, than touch many plugins for many reasons. It should only
>> effect other plugins where it is absolutely necessary to do so. We can
>> surface objects quite effectively there to QtScript.
> 
> Ok, you made a point here. So let's create a script plugin and put all script 
> interfaces into it (instead of spreading it in all other plugins).
> I would also move the ScriptManager and the script engine into the plugin, 
> instead of keeping it in core (like you did in the code you pointed me too).
> 
>> This project over here:
>> http://gitorious.org/qt-creator-static-code-quality-plugin gives a good
>> jump off point/proof of concept that it can work this way. It also gives a
>> good use-case as well :)
> 
> Interesting use case, totally different than mine, which is good.
> As Eike said, let's talk of what we want to do with the scripts. Here is my 
> personal list of must have:

Sounds like a good list to start with. Things like direct access to registered actions sounds well maintainable & already useful.

> * list of projects
> * list of files in a project
> * open any file
> * access the current editor
> * search/replace/edit in the editor
> * call some actions (there's already a scriptable boolean for that)
> * display and write things in the application output pane (or create a script 
> output maybe)

The "General" output is already used for stuff like external tool output, not much else is put there, so I'd think that would be fine.

> * access build issues pane (perfect for Bill's use case)
> 
> Things that would be nice:
> * access refactoring
> * access the AST, and be able to manipulate it
> * add/remove files to project
> 
> I'm going to start by creating the script plugin: move the ScriptManager into 
> this plugin, provide a way to add a script and run it. Then we can discuss a 
> bit more about the interface.
> 
> Cheers,
> Nicolas
> 
> -- 
> Nicolas Arnaud-Cormos | nicolas.arnaud-cormos at kdab.com | Senior Software 
> Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090
> KDAB - Qt Experts - Platform-independent software solutions

-- 
Eike Ziller
Principal Software Engineer

Nokia, Qt Development Frameworks

Nokia gate5 GmbH
Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany
Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B
Umsatzsteueridentifikationsnummer: DE 812 845 193
Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori