Re: GSoC Proposal: Scripting Framework for Applications

[Shaneeb Kamran <shaneebster gmail com>]

On Mon, Apr 5, 2010 at 1:04 AM, Johannes Schmid <jhs jsschmid de> wrote:

Well, we have gobject-introspection and at least _javascript_ uses it to
be able to connect to any API availabel in GNOME. Python is going to use
it soon. So there is no problem in limiting the developer to a single
language.

I am not entirely sure but my guess is adding support for another language would require modifications to all the applications individually that want its support to be included. As far as I have read (I apologize if I am wrong) GObject-introspection just makes language bindings pretty straightforward but to be able to use a language for scripting requires more than bindings; there are other issues involved for example, mechanism for invoking the script, passing objects, data conversion from the scripting language to the language of the application (usually C\C++), etc.

 

And for the plugin framework and don't think it possible/feasible to
unitfy it as "plugins" are different things in different applications.
In gedit plugins enhance the core functionality while for example in
anjuta, the whole application is put together with different plugins as
an architectural choice and you would just see an empty menu bar if no
plugins are loaded. This is simple no "User scripting". I wonder if the
would be a common layer that would work for both extremes and if that
wouldn't impose new implications.

The two uses-cases I mentioned are similar to what you are suggesting. In my opinion, these two extremes do seem to have a fair bit of similarity and hence they can be supported using a single scripting framework. Moreover, attempting to unify them would save some code bloat since a single solution is always better than two overlapping ones.

 

I think there are more interesting opportunities for example to make
sure that any of the GNOME core applications support full
gobject-introspection of there plugin API that would bring GNOME much
more forward.

You reinforced my point ;-) . Having a proper scripting framework would avoid having to modify/update each application individually in order to support any new technology in future. Same goes if for example, as you say, python bindings become more mature: individual applications would not have to be updated to add support for this new language.

 

Regards,
Johannes

Am Montag, den 05.04.2010, 00:48 +0500 schrieb Shaneeb Kamran:

> Hey, I am a undergraduate student of Computer Engineering from
> Pakistan. I am very excited about availing the Summer of Code
> opportunity to contribute to the GNOME project. The idea I am
> proposing is a scripting framework for GNOME applications and it is
> inspired by the Kross scripting framework that is available for KDE
> apps.
>
>
> The need for scripting support in applications is two-folds. These two
> different use cases are as follows:
>
>
> 1) Plugins aka User Scripts: Allow third-party developers to enhance
> or add features to the application
> 2) Embedding: Make an efficient native-compiled core and use more
> productive languages to add the front-end on top such as UI, or to
> glue together different base components to form a complete
> application.
>
>
> However, at present there are a few problems/limitations associated
> with such scripting support. Firstly, most applications that currently
> employ scripting support have limited themselves to one language. This
> approach has disadvantages in that the users are forced to use that
> particular language to add their own customizations/enhancement to the
> application even if its a trivial one. This may discourage the user
> from writing such an enhancement at all if he is not proficient in the
> scripting language of the application and has to learn it. Moreover,
> different languages have different features which are very suitable
> for a specific problem domain. For example, Perl has good support for
> text processing, Python makes 'gluing' components together very easy,
> _javascript_/Lua are lightweight and well suited for embedding uses,
> etc. Limiting the user to only one language prevents him from using
> such features which might be available in other languages.
>
>
> Secondly, there is no one common/unified implementation that attempts
> to cover maximum possible use cases. Most applications that currently
> employ scripting support have each come up with their own unique
> solutions e.g. Evolution's EPlugins, GEdit's plugin system, Anjuta
> plugin framework, etc. Having one common implementation has advantages
> including code reuse of backend plugins (if a new plugin for a
> language is written then all applications using the framework will be
> able to use it), API reuse( that is the application programmer needs
> to learn only one API in order to add scripting support in multiple
> applications) and consistent functionality/behavior across
> applications from the user's point of view (quirks?).
>
>
> Hence, the goals of the project are:
> 1) Easy and transparent scripting support for applications
> 2) Isolate the application from the details of interfacing with the
> interpreter
> 3) Language Independent
> 4) Cover maximum possible use cases of scripting
> 5) Code Reuse - Backend language plugins reusable by applications
> 6) Efficient Implementation
>
>
> Your criticism, suggestions, opinions... ?
>
>
> --
>
> Regards,
> Shaneeb Kamran

> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list

I am still learning and I can be wrong. In case I am, my apologies.

--

Regards,
Shaneeb Kamran