Re: GSoC Proposal: Scripting Framework for Applications
- "Colin Walters" wrote: > On Thu, Apr 8, 2010 at 2:56 PM, Shaneeb Kamran > wrote: > > > The main benefit of supporting multiple languages is more to the > users of > > the application than to its developers. Like I mentioned in my > previous > > mails, if a user wants to add a feature to his favorite application > and he > > knows only a language, say, ruby while the app requires him to write > the > > extension in, say, python then the user is stuck: he has to learn a > new > > language just to write a small piece of code. > > We can't support multiple runtimes per process sanely for a variety > of > technical reasons; one of those is that multiple GC'd runtimes break > toggle references useless and lead to memory leaks. A non-technical > argument against this is that it fragments the developer base, > documentation, etc. > > My take is that GNOME apps should pick C + one of JS,Python and move > on with actually writing your app and fixing bugs, making it > compelling, etc. I would have to agree here. As a project the proposal has merit but the issues involved make it a poor candidate for an SoC funded project. I would much more like to see a project which adds scripting (JS or Python) to a number of applications in the GNOME stack. Or one that documented best practices for applications exporting plugin hooks. Those seem to be much more useful once the SoC period has ended. SoC should be about improving on existing projects, not creating whole new projects because the time allotted isn't really long enough to start something from scratch. For that reason a project should prove itself outside of the SoC framework before we consider it for funding. In other words a developer should be enthusiastic enough about a project to develop it regardless of funding. -- John (J5) Palmieri Software Engineer Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSoC Proposal: Scripting Framework for Applications
On Thu, Apr 8, 2010 at 10:06 PM, Colin Walters wrote: > On Thu, Apr 8, 2010 at 2:56 PM, Shaneeb Kamran wrote: > My take is that GNOME apps should pick C + one of JS,Python and move > on with actually writing your app and fixing bugs, making it > compelling, etc. That would be my plan for world domination as well except that I think its time all gnome developers stop wasting their time writing code in C while they can achieve the exact same results using Vala in far less time and efforts without introducing performance overhead or dependencies. Moreover, we'll get gobejct-introspection support for free. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSoC Proposal: Scripting Framework for Applications
On Thu, Apr 8, 2010 at 2:56 PM, Shaneeb Kamran wrote: > The main benefit of supporting multiple languages is more to the users of > the application than to its developers. Like I mentioned in my previous > mails, if a user wants to add a feature to his favorite application and he > knows only a language, say, ruby while the app requires him to write the > extension in, say, python then the user is stuck: he has to learn a new > language just to write a small piece of code. We can't support multiple runtimes per process sanely for a variety of technical reasons; one of those is that multiple GC'd runtimes break toggle references useless and lead to memory leaks. A non-technical argument against this is that it fragments the developer base, documentation, etc. My take is that GNOME apps should pick C + one of JS,Python and move on with actually writing your app and fixing bugs, making it compelling, etc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSoC Proposal: Scripting Framework for Applications
On Thu, Apr 8, 2010 at 1:57 AM, John Palmieri wrote: > > - "Shaneeb Kamran" wrote: > > > On Tue, Apr 6, 2010 at 9:24 PM, Johannes Schmid < j...@jsschmid.de > > > 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. > > > > > > > > Are the "bindings" the only thing required to properly interface two > > languages together? What about data-type mapping, data marshalling, > > memory management issues, etc? Since we have introspection now, all > > our problems are solved? Correct me if I am wrong but libraries such > > as GJS are meant to handle precisely these issues. > > > > > > But that still is not the main concern of the project; these issues > > are supposed to be handled by specific language plugins (GJS would be > > treated as a language plugin). Moreover as you say, JavaScript support > > is out (GJS) and python support will be complete soon as well > > (PyGObject?). Great, any application can now link to these two > > libraries and use two languages. What if someone writes support for a > > third language, say ruby. Your application will need to be modified to > > use that library and add another dependency. Now libraries to add two > > more languages' support, say Java and .NET, are created. So your > > application will need to add yet more (bloat) code, add another two > > dependencies raising the total number of dependencies to four. Now Lua > > supports comes in... > > > > > > The cycle continues. > > > > I perhaps failed to clearly highlight the main goal of the project: > > enable an application to add scripting support, without regard to any > > particular language, i.e. cross-language. Specific languages plugins > > will then be loaded at runtime (read: no static dependency) which will > > handle all the issues mentioned above plus generate "bindings" via > > GObject-introspection as well. > > > > > > The project is very much inspired by the Kross scripting framework > > which is available to KDE developers ( > > http://www.techbase.kde.org/Kross ) > > So what GObject Introspection gets you is the ability for bindings that > understand GObject Introspection to instantly load those modules and use > them in the language's interpreter. It doesn't instantly allow any app to > load a plugin written in any language. For instance gnome-shell uses the > gjs interpreter and exports functions and objects through GNOME > Introspection. You can't write a python plugin unless the shell decides to > embed a python interpreter. Marshalling data isn't an issue here unless you > wanted to somehow allow different language modules to talk to each other. > > Basically what you would be doing is writing a meta interpreter which would > provide a framework for developers to add plugin support without worrying > about which interpreter they would be using. I see a couple of downfalls to > this approach - specifically security, performance and issues with some > languages not being supported on one or another system. I'm also not > convinced, without a common runtime like .net and given that the client side > of the web has survived pretty well without the need of multiple languages, > it is something we wish to encourage. That being said, the proposal itself > has some merit as a project. > > I wouldn't say its a 'meta interpreter' but yes that is the basic idea. IMO, performance wont be an issue since there will only be a thin layer over the language plugins (which will have interpreters embedded in them). Security can be an issue, but then how does GJS or other existing libraries provide any protection? Besides, there is always the option of introducing some 'restriction mechanism' (if the project becomes mature) such as allowing only "signed" scripts to be executed. The main benefit of supporting multiple languages is more to the users of the application than to its developers. Like I mentioned in my previous mails, if a user wants to add a feature to his favorite application and he knows only a language, say, ruby while the app requires him to write the extension in, say, python then the user is stuck: he has
Re: GSoC Proposal: Scripting Framework for Applications
- "Shaneeb Kamran" wrote: > On Tue, Apr 6, 2010 at 9:24 PM, Johannes Schmid < j...@jsschmid.de > > 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. > > > > Are the "bindings" the only thing required to properly interface two > languages together? What about data-type mapping, data marshalling, > memory management issues, etc? Since we have introspection now, all > our problems are solved? Correct me if I am wrong but libraries such > as GJS are meant to handle precisely these issues. > > > But that still is not the main concern of the project; these issues > are supposed to be handled by specific language plugins (GJS would be > treated as a language plugin). Moreover as you say, JavaScript support > is out (GJS) and python support will be complete soon as well > (PyGObject?). Great, any application can now link to these two > libraries and use two languages. What if someone writes support for a > third language, say ruby. Your application will need to be modified to > use that library and add another dependency. Now libraries to add two > more languages' support, say Java and .NET, are created. So your > application will need to add yet more (bloat) code, add another two > dependencies raising the total number of dependencies to four. Now Lua > supports comes in... > > > The cycle continues. > > I perhaps failed to clearly highlight the main goal of the project: > enable an application to add scripting support, without regard to any > particular language, i.e. cross-language. Specific languages plugins > will then be loaded at runtime (read: no static dependency) which will > handle all the issues mentioned above plus generate "bindings" via > GObject-introspection as well. > > > The project is very much inspired by the Kross scripting framework > which is available to KDE developers ( > http://www.techbase.kde.org/Kross ) So what GObject Introspection gets you is the ability for bindings that understand GObject Introspection to instantly load those modules and use them in the language's interpreter. It doesn't instantly allow any app to load a plugin written in any language. For instance gnome-shell uses the gjs interpreter and exports functions and objects through GNOME Introspection. You can't write a python plugin unless the shell decides to embed a python interpreter. Marshalling data isn't an issue here unless you wanted to somehow allow different language modules to talk to each other. Basically what you would be doing is writing a meta interpreter which would provide a framework for developers to add plugin support without worrying about which interpreter they would be using. I see a couple of downfalls to this approach - specifically security, performance and issues with some languages not being supported on one or another system. I'm also not convinced, without a common runtime like .net and given that the client side of the web has survived pretty well without the need of multiple languages, it is something we wish to encourage. That being said, the proposal itself has some merit as a project. -- John (J5) Palmieri Software Engineer Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSoC Proposal: Scripting Framework for Applications
On Thu, Apr 8, 2010 at 1:19 AM, Shaneeb Kamran wrote: > > *The project is very much inspired by the Kross scripting framework which > is available to KDE developers (http://www.techbase.kde.org/Kross)* > >> >> Sorry, incorrect address. You can try at http://en.wikipedia.org/wiki/Kross_(KDE) and http://kross.dipe.org/ -- Regards, Shaneeb Kamran ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSoC Proposal: Scripting Framework for Applications
On Tue, Apr 6, 2010 at 9:24 PM, 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. > Are the "bindings" the only thing required to properly interface two languages together? What about data-type mapping, data marshalling, memory management issues, etc? Since we have introspection now, all our problems are solved? Correct me if I am wrong but libraries such as GJS are meant to handle precisely these issues. But that still is not the main concern of the project; these issues are supposed to be handled by specific language plugins (GJS would be treated as a language plugin). Moreover as you say, JavaScript support is out (GJS) and python support will be complete soon as well (PyGObject?). Great, any application can now link to these two libraries and use *two *languages. What if someone writes support for a third language, say ruby. Your application will need to be modified to use that library and add another dependency. Now libraries to add two more languages' support, say Java and .NET, are created. So your application will need to add yet more (bloat) code, add another two dependencies raising the total number of dependencies to four. Now Lua supports comes in... The cycle continues. I perhaps failed to clearly highlight the main goal of the project: enable an application to add scripting support, *without regard to any particular language, i.e. cross-language. Specific languages plugins will then be loaded at runtime (read: no static dependency) which will handle all the issues mentioned above plus generate "bindings" via GObject-introspection as well. * * * *The project is very much inspired by the Kross scripting framework which is available to KDE developers (http://www.techbase.kde.org/Kross)* > > > 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. > > > Covering the two use cases (plugin + embedding) is not the main focus of the project. Let me rephrase it as covering the 'maximum possible usage scenarios'. If its not possible to unify embedding and plugin usages then let it be so; I will not attempt to cover both usages in such a case ;-) ... My point was that we shouldn't restrict ourselves to only a single use case but rather make it as general as possible. Plus I wanted to make a stronger case for my proposal ... ;-) > > > 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". > > If your not happy with "framework", suggest a word you like better. I only used it since the KDE folks call their implementation (Kross) a 'scripting framework' so I just reused that phrase. And maybe you are right, its not a complete framew
Re: GSoC Proposal: Scripting Framework for Applications
Hi! > You still need to add support by hand - otherwise there would be no > 'javascript only' gnome-shell. Well, the shell is javascript-only because it is itself written in javascript. You cannot bind anything to Javascript, you can just bind it to C. gnome-shell is a mutter plugin, mutter is written in C. > 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. There may be some code necessary to actually load a plugin but it can also be done in a way that the plugin itself contains some C code (probably just some macros) to behave like a C plugin from the outside and loading its language itself. This part is probably interesting if someone wants to mentor it but it's not really that much work. And keep in mind that plugins usually have metadata files (anjuta uses GKeyFiles) to query information before loading the plugin. Maybe you could write some library that handles the metadata and the loading but it would need to be adapted and added to the gnome code components to be useful. Anyway, if someone would want to mentor it - why not. But it's definitly no scripting framework, it's a plugin library (and there are already a few out there). Regards, Johannes signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSoC Proposal: Scripting Framework for Applications
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 signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSoC Proposal: Scripting Framework for Applications
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 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSoC Proposal: Scripting Framework for Applications
2010/4/4 Johannes Schmid : > 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. There already is a GnomeGoal for this, take a look here [1] to check the actual status [1] http://live.gnome.org/GnomeGoals/AddGObjectIntrospectionSupport -- Javier Jardón Cabezas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSoC Proposal: Scripting Framework for Applications
On Mon, Apr 5, 2010 at 1:04 AM, Johannes Schmid 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 > > appli
Re: GSoC Proposal: Scripting Framework for Applications
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 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GSoC Proposal: Scripting Framework for Applications
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
GSoC Proposal: Scripting Framework for Applications
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
