Re: GSoC Proposal: Scripting Framework for Applications


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

That's not true. By adding gobject-introspection you get
language-bindings for at least JavaScript and Vala out of the box and
python is planned. There is nothing else to do as the bindings are
constructed a runtime (vala: compile-time) from the introspection files.

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

Well, would a single solution have so much benefit? Of course you might
be able to unify the way plugins are loaded and plugin descriptions are
designed but this is actually not much code as most things a handled by
GModule anyway.

Much more important is the point that any application has it's own
plugin API anyway, as the plugins have to interact with the internal
architecture of the application. 

Example: gedit and anjuta both use gtksourceview. But a plugin in gedit
is able to interact directly with the gtksourceview class while anjuta
supports different editors and as such has an interface called
IAnjutaEditor which is used to interact with the editor. A unified
framework won't help you here at all.

> 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.
See above. The internal APIs need to be exposed anyway and
gobject-introspection is the best way to do it. I wonder what would be
left for the "Scripting Framework".

BTW, could you explain what components this scripting framework should
have, which languages it would support, etc.?


Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]