Internal scripting interface
Currently MkS developed only in C++ programming language, all data and is hardcoded in code, all plugins is written on C++/Qt.
It creates us some problems:
Next data is hardcoded in C++ code:
if( | )
It creates next problems:
Example - PHP developer wants to add abbreviations for PHP and support of parsing PHP interpreter errors.
Abbreviations editor and lexers associations editor implemented in settings screen.
Plugins only in C++
Problem is the same, as with data.
Only C++/Qt programmer can do something for MkS. MkS internal structure is not so clear, just because MkS is already big enough, so, even C++/Qt programmer need big enough time for create some extension.
MkS is not extensible.
For try to fix this problems, I offer to start development MkS internal scripting interface.
MkS internal scripting interface
It will be textual interface, similar with Unix shell.
It will allow to store all data in textual files, which is easy for modification by users/developers; and, later, create plugins in any languages, which uses only MkS internal scripting interface. Such plugins can be written on any programming language.
Development of such interface can be divided on few stages.
Stage 1: Export data from code to textual files
On this stage we can export some data to script files. The easy way for explain it it example. For make possible to build projects on Windows MkS set some environment variables (path to Qt, compiler, make utility)
We could store this variables in the settings, and create editor in GUI for it, but, it creates all mentioned problems.
File will be stored somewhere in startup dirrectory and processed every time at start.
Else one example. Abbreviations. The Python programming language have construction:
Let's imagine MkS internal scripting interface supports command
(of course there will be not only this abbreviation)
Stage 2. Non interactive plugins
It will be similar with stage 1 configuration files, but it will be scripts, written on any scripting language, and it will have possibility to install/uninstall self.
Example of such kind of plugin is Gcc parser, which contains set of parsing patterns. Plugin adds pattern to core on installation, and removes from core on uninstall.
I'll describe this stage later.
Stage 3. Fully interactive plugins.
Such plugins as debuggers, builders, version control systems can be coded on some high-level scripting language, and integrated with system using scripting interface.
It will receive commands and events from core and send commands and own events to it via textual interface.
We can divide plugin on to 2 parts:
Example: Subversion plugin.
event fileopened /home/a/code/mks/debugger/main.cpp
checks file status, and sends command