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