Re: New propossed GnomeGoal: ValidateGtkBuilderFiles
2010/4/8 Javier Jardón jjar...@gnome.org: I think the GnomeGoal is small, well defined, broadly applicable and useful. See this giggle commit as an example [3] Can't we put stuff like test_gtkbuilder_file_validation.sh in gnome-common? Seems a bit of a waste to add this to all files. Richard. ___ 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 jo...@redhat.com wrote: - Shaneeb Kamran shaneebs...@gmail.com 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 to learn a new language just to write a small piece of code. If I may give an example from proprietary software, Microsoft
Re: GSoC Proposal: Scripting Framework for Applications
On Thu, Apr 8, 2010 at 2:56 PM, Shaneeb Kamran shaneebs...@gmail.com 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: New propossed GnomeGoal: ValidateGtkBuilderFiles
hi, Am 08.04.2010 02:54, schrieb Javier Jardón: Hello, Paolo Borelli proposed me to create this GnomeGoal inspired by the recent Murray post [2]. The idea is to validate our xml GtkBuilder files before we release new tarballs (in 'make check' and 'make distcheck') I think the GnomeGoal is small, well defined, broadly applicable and useful. See this giggle commit as an example [3] You can see all the info in the GnomeGoal page [2] Comments welcomed! [1] http://www.murrayc.com/blog/permalink/2010/03/30/testing-glade-files/ [2] http://live.gnome.org/GnomeGoals/ValidateGtkBuilderFiles [3] http://git.gnome.org/browse/giggle/commit/?id=ffdf46a78550b980520659b7e9d90a321b14cb99 +1 this is a good idea for all kind of xml files. gtk-doc does this for the manuals. Stefan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New propossed GnomeGoal: ValidateGtkBuilderFiles
On Thu, 2010-04-08 at 01:54 +0200, Javier Jardón wrote: Hello, Paolo Borelli proposed me to create this GnomeGoal inspired by the recent Murray post [2]. The idea is to validate our xml GtkBuilder files before we release new tarballs (in 'make check' and 'make distcheck') I think the GnomeGoal is small, well defined, broadly applicable and useful. See this giggle commit as an example [3] You can see all the info in the GnomeGoal page [2] Comments welcomed! I've attached a basic RELAX NG schema. Validate like this: xmllint --noout --relaxng gtkbuilder.rng /path/to/file.ui This is very basic, but it's better than nothing. I'd like to make it more extensible so we can wrap it with a customization schema that checks the validity of the various extensions used by GTK+ widgets. That could in turn be wrapped by extensions to check for specifics of other libraries. Enjoy, Shaun gtkbuilder.rng Description: XML document ___ 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 walt...@verbum.org wrote: On Thu, Apr 8, 2010 at 2:56 PM, Shaneeb Kamran shaneebs...@gmail.com 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
- Colin Walters walt...@verbum.org wrote: On Thu, Apr 8, 2010 at 2:56 PM, Shaneeb Kamran shaneebs...@gmail.com 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
