Re: Scripting in Gnome

[Martin Grimme <martin pycage de>]

Hi,

Am Fr, den 30.01.2004 schrieb Tim Peoples um 15:46:
> Along these lines, I've had an idea bouncing around in my head for
> a few months now.  Somewhat of a marriage of glade (the xml format),
> javascript, Gtk+/Gnome bindings and some sort of web service protocol
> (xml-rpc or maybe soap/wsdl) into something I have initially called
> "Gnomescript".  While I only have a cursory understanding of DBUS, it
> definately looks like it fits in quite nicely.

This sounds like a great idea and I actually want to push gDesklets into
that direction within the next few months.
We aleady have a lightweight XML format for user interfaces
(currently we only cover things like labels and images but standard
widgets may be added). Inline scripting (i.e. the marriage of XML with
Python scripts) will be added in the 0.30 release. We focus on Python as
the scripting language but other inline scripting languages may easily
be added by implementing interpreter functions (which are usually C
code).

I consider the Glade XML format not being appropriate for your idea,
because Glade XML turns out to be not very human-readable, IMHO.


> I'll admit that I haven't put much work into it after my initial frenzy
> of binding a few Gtk+ widgets into Mozilla's SpiderMonkey... mostly
> because I was somewhat leary of whether such a beast was really
> necessary or not (like was said elswhere, we already have Python and
>  Perl and ....)

Such a "beast" would be the perfect thing for applets (panel and
desktop), capplets, small tools, ...
Windows Longhorn will feature Avalon which lets you write user
interfaces with XML and script it using some scripting languages.

> Originally, my idea was leaning more towards "remote applications"
> somewhat like Mozilla's XUL but much more Gnome specific... but soon
> expanded that to something more akin to VB on Windows (but without
> all the ugly baggage the VB carries).  You'll have to admit that the
> availability of VB on Windows in the early nineties somewhat helped
> MS achieve their dominance on business desktops.

Remote desklets can be executed wherever a gDesklets interpreter is
installed. This already works and you could e.g. execute .display files
that are on some http:// location or any other GNOME VFS accessible
location.

> All that said, I still do have plans to pick this up again... that is,
> unless I can be convinced that its not worth the effort (which may not
> be all that hard to do).

gDesklets might still be a "geek toy" right now, but with some work, we
could push it into the right direction to become an Avalon competitor.
And this is the direction where I want to see that project go.

gDesklets is mostly written in Python and some people may consider this
as overhead for such a project. But if you want to have scripting in
XML, you need a script interpreter, so you'll always end up with having
one in memory. So I guess, the overhead argument no longer counts.

By embedding interpreters into shared libraries, we could have
interpreters for several scripting languages around with many programs
using them, but with only one interpreter instance per language in
memory.
Right now, each Python program e.g. would start its own Python
interpreter, which may not be desired (gDesklets uses only one Python
interpreter, no matter how many desklets are active, though).


Martin