[Qt-creator] Extending Qt Creator with scripts

[eike.ziller at nokia.com]

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. (We'll see what happens in Qt5 later, QtScript will be in "only critical bug fixes" mode in Qt5, and instead a "similar" interface to the V8 javascript engine is supposed to be provided. At least I suppose that Qt Creator will move to Qt5 at some point in the future, though not in the *near* future.)

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 suppose it would be good to write down what script API would be needed for a few use cases (like the editing macros, maybe a few other things), to get a better idea how much API would actually be required for these use cases, and if it would make sense to maintain such API manually.
We'd need to provide separate documentation about the script interface to the user, if we create a separate, manual one.

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.

Br, Eike

On 30 Oct 2011, at 19:51, ext Nicolas Arnaud-Cormos wrote:

> Hi all,
> 
> Qt Creator is one of my favorite IDE, unfortunatelly there's something I'm 
> still missing compare to xemacs: scripting.
> In my day to day work, I'm using xemacs most of the time because of existing 
> scripts for this particular project. Also, we all have some specific tasks we 
> do again and again in a project, and creating a new plugin each time would be 
> a pain.
> 
> I would like to work on this, but before starting anything let's discuss the 
> architecture a bit here (and maybe on IRC), so I would be able to push it 
> upstream.
> 
> Langage
> =======
> I'm thinking of javascript, for 2 reasons: it's supported by Qt Script, and 
> QML developpers know it.
> I considered QML 5 seconds, but I don't see how a declarative langage (mainly 
> for creating graphical interface) can be used here, and what we would gain.
> So my primary goal is javascript using Qt Script.
> 
> Script manager
> ============
> There's already a ScriptManager class in core, not used, with already some 
> nice things. This ScriptManager is used to start the engine with all the Qt 
> Creator interfaces registered.
> Seems like a good decision, and I'll revive this class.
> 
> Qt Creator interfaces
> =================
> There's not much code right now, but it seems that the direction taken by 
> ScriptManager is to do a 1:1 mapping with QtCreator.
> For me, it doesn't make sense, scripting must be fast and easy. 
> I would propose to create an object (or maybe more than one) for each plugin, 
> with methods we want to export to javascript.
> 
> For exemple, for a cppplugin, I would like to write something like this (more 
> or less, but you get the idea):
> if (isCppFile())
> 	editor.switchDeclarationDefinition()
> 
> Script plugin
> ==========
> The script plugin will manage the script files (directories, delete,  
> create...).
> Like the macro plugin, a way to execute a script using the locator, and a way 
> to assign shortcuts to scripts.
> So except the engine (in ScriptManager... maybe rename it to ScriptEngine) and 
> the plugins interfaces, everything script related should be in this plugin.
> 
> Macro plugin
> ==========
> That's the last target of my project: replacing the current macro plugin by 
> something which create scripts.
> So instead of storing key events (press 's' key, release 's' key...), I would 
> store editor->write("slots") in a script. It should also fix some issues of the 
> current macro plugin...
> 
> 
> Any comments are very welcome, either here or on IRC (nikikko).
> 
> 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
> _______________________________________________
> Qt-creator mailing list
> Qt-creator at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator

-- 
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