On Tue, 2010-04-06 at 18:24 +0200, Johannes Schmid wrote: > 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. > If I understand you still need to *load* plugins. While gobject-introspection do simplify exporting/importing objects (in runtime or compile time) it does *not* handle loading scripts and running hooks. You still need to add support by hand - otherwise there would be no 'javascript only' gnome-shell. > > > 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. > I'm not quite sure how much code/time is spent on this but you still need to hook the single languages into the stack. Last time I checked C/python/vala was used. gnome-games seems to use a bit guile. If user knows lua/ruby/fortran/shell/javascript - he's out of luck. > > > 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.? I cannot answer for author but I'd imagine that: - Searching plugin directories for plugin - Detecting the language of plugin (ok. assembler is not the language plugin is written in but that's different matter). - Loading/unloading plugins according to given configuration. Setting the python/guile/haskell/lua/tcl/brainf*ck/whitespace/javascript environment. Possibly it should handle dependencies between plugins. Probably languages should be GModule plugins itself. I don't know if it is enough for GSOC project but it is at least so boring task many programs have no more then native+python scripting. Regards
Attachment:
signature.asc
Description: This is a digitally signed message part