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:

Data hardcoding

Next data is hardcoded in C++ code:

• Abbreviations. ife abbreviation expanded to:

if( | )
{
}
else
{
}

• File name: language associations ( .cpp,.cc,.h: C++)
• Patterns for parsing output during build progress
• Default settings. Exception is only templates, it is stored in files, but, file format is really ugly.

It creates next problems:

• Data is hard to change. You need find it at code,fix and rebuild MkS.
• C++ code grows, because it consists this data
• Data can be changed only by C++/Qt programmer.

Example - PHP developer wants to add abbreviations for PHP and support of parsing PHP interpreter errors.
He can't because he can't find our abbreviations in C++ code, he don't knows, how to write in C++, he haven't development Qt version and C++ toolchain for build MkS.

• We have to create editors for our data, if we want to allow user change it. It requires time for coding and makes our code base bigger.

Abbreviations editor and lexers associations editor implemented in settings screen.
Templates editor is not implemented, because it's too hard for implementation.

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)

PATH=C:\Qt4.4.3\bin;D:\MinGw\bin:%PATH%
QMAKESPEC=win32-msvc2005

We could store this variables in the settings, and create editor in GUI for it, but, it creates all mentioned problems.
With scripting interface, we will have MkS command setenv, and environment config will be stored in the next file:

setenv PATH=C:\Qt4.4.3\bin;D:\MinGw\bin:%PATH%
setenv QMAKESPEC=win32-msvc2005

File will be stored somewhere in startup dirrectory and processed every time at start.
When user wants to change settings, we just open file in the editor for him. I think it's not a problem for every user to understand and edit such file.

Else one example. Abbreviations. The Python programming language have construction:

try:
\t
except:
\t

Let's imagine MkS internal scripting interface supports command
abbreviation add {language} {short text} {full text}
When python programmer wants to write MkS extension (plugin) for better Python support, he will create file will create file 'python_abbreviations.mks' with next content:
abbreviation add 'Python' 'try' 'try:\\n\\except:\\t\\'
...

(of course there will be not only this abbreviation)
Than programmer will put this file to MkS startup directory, and have support of python abbreviations.
After it he will send his files for MkS team, and python abbreviations support will be included to official version.
Also programmer can send file to his friend.
If we store abbreviations in the MkS settings, programmer can't export it and send to friend.

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:

• Binary part (dll), which extends core with new commands/events support, GUI dialogs. Written on C++/Qt. It must be as little as possible.
• Part, written on scripting language. Implements business logic of plugin.

Example: Subversion plugin.
When file is opened, we want to show file status on the status bar. (one of features)
Binary part provides support of core command versstatus {status}. This commands changes value on the status bar.
Plugin, written on Python, C#, Perl, Java or any other language, works with version control system. When file opened, plugin receives event

event fileopened /home/a/code/mks/debugger/main.cpp

checks file status, and sends command

versstatus conflicted