Hi! > 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.? Regards, Johannes
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil