On Mon, Apr 5, 2010 at 1:04 AM, Johannes Schmid <[email protected]> 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 > > [email protected] > > 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
_______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
