This is as days pass by, by Stuart Langridge

Absolutely worth any time you have.

Designing a language seems to be a waste of time with all that fancy ng ones around today. But having a "natural speaking in a well-defined environment" is definitely something exciting.

I have some advice if you really want to go on that road:

1. allow "remember that as " statements (maybe with tuples)

2. use little to no data types - keep it as abstract as possible

3. allow scripts to be registered as a dbus service

4. do not call it linglish! please!

5. think of allowing translated keywords - that would be a great thing

Make it a Gnome-Do plugin!

I did something similar once (though my language was written in a different context), and at the start I swore that I would NEVER let it grow out of control. Two years later, the syntax became a growing pain.

"This will never be (and is obviously never intended to be) a replacement for a proper language"

This is the key question. Personally I have no doubt that, if persued for more than a few weeks, this language will grow to a point where one of two things will happen:

- Development is stopped, because most scripts aren't trivial enough to work that way.

- It will grow to a point where the design decisions that made things easy in the beginning will become a pain.

The problem is that once you have started a small script, re-writing it in a "real" language is often a lot more work than adding support for the missing feature to your language.

Personally, I think that this is inevitable, and the end result will probably be hard to use, so you might as well start with an existing language.

The following Python code isn't much harder, but probably still saner in the end.

screensaver.lock()

banshee.window.present()

(By declaring lock/present properties you can even get rid of the brackets.)

Looks neat :)

I think that desktop scripting needs to be thought of very differently from CLI scripting. With a CLI, everything happens in a straight line of commands, but with a desktop that is much more blurred. The text-based script is right at home in a text-based shell, but it just doesn't fit as intuitively in the windowed GUI environment.

I think a graphically oriented - maybe node based - scripting language based on a similarly juicey d-bus thing would rock!

And that d-bus stuff is VERY juicey. Good luck.

for a start don't think about translation.

programming in english makes sense, especially when there are just 10 basic commands (words) to use in such an easy "language", why bother to mess with foreign words and even grammar..

i think it is a nice idea, even though personally I am not afraid of using DBUS directly for such small commands.

Could come in very handy though to achieve nice things as:

tell cheese to photograph

tell evolution to mail photograph to bill@microsoft.com

ie: the name of the returned value should be fixed.

so that we don't have to mess with "remember value as foo".

that would be revolutionary and easy.

for example if I query banshee's last played song it is just 'last_played_song' :)

So no conjuctions?

tell cheese to photograph and email photograph to submissions@amihotornot.com

The signal part that you talk about at the end would be the most interesting I think for people that want to tie together several actions when an event fires off on the bus, but not one they necessarily initiated themselves. For example I think people would really like to be able to script something like:

wait for workrave's break

tell banshee’s playerengine to pause

tell pidgin's status to away

tell screensaver to lock

Your syntax would make that a lot more accessible for a wider set of people. Nice idea!

i agree with knipknap -- no point in masking a formally defined language as text. if you want to do just that, use the shakespeare language http://shakespearelang.sourceforge.net/. otherwise, it's better to use something like python, lua or pawn

sil: what do you think about fixed names for the return values?

maybe if the syntax was different like:

get banshee's actual song

then it would make many sense to be able to reuse in in a way like:

send actual song's file to eric@google.com

It sounds nice, but I don't think it's worth it.

Why - because I don't think most people are interested in scripting their desktop like this really. Those who'd like to tinker are fine with learning bash / python and etc. Or programmers who would like to implement certain functionality in their program.

What would be much better is lowering the entry level to dbus, python etc - the documentation is lacking, all over the place, and a hell to start with as I recently found out.

I'd be interested in a better documented manner in scripting things from the bash shell. A lot of power users are able to script in bash, and yet the documentation on how to script dbus from bash is difficult to find.

After that, I'd provide bindings for lua or tcl or other "high level" langauge. Trying to write in a language that thinks it's like english is harder (because you end up fighting bad grammar) than learning to write in a simple scripting language, and you get a lot of things for free (for example, complicated, nested datastructures). I'd not use perl (too many tricky ways to do things), nor python (things like indentation make it difficult to just pick up). Lua is a nice simple language that offers a very shallow learning curve.

If you want something that is deliberately aimed at end users, then perhaps something less like a programming language, and more like a gui flowchart designer would be better.

maybe besides tell (for void functions) I would use the get and set keyword (especially get for return values)

instead of:

tell gnome to set language to english

one would write:

set gnome's language to english

or:

tell banshee to return the actual song

:

get banshee's actual song

but as pointed out in previous comments, this can easily lead to a bloated language as more and more keywords get introduced...

Tab completion. D-Bus is horrible to find your way around unless you already know it well, and anything tab-completable would help.

Some idea of which calls are deprecated and which aren't. Any non-trivial and reasonably long-lived API has deprecated bits, and it would be a shame if users were encouraged to rely on them (it's a lot easier to get programmers to update, and even then it's a pain in the arse).

Same concern as knipknap. Having a very simple language for this kind of scripting seems an admirable goal, good for solving simple problems. But simply problems have a tendency to become more complicated, and what happens then? Will the language itself evolve to support that, losing the simplicity that made it attactive? Or will users hit a hard limit in what can be done, and at that point, have to rewrite everything they've done in a new language?

Honestly, I think it may be better to just start with a more general-purpose language. It may be harder to get started, but I think it would be better to work on alleviating that initial hit (e.g with more beginner-friendly APIs) than to do something that will hit more serious limitations once they try to grow.

Python has been used before to create almost-domainspecific languages. I also might lean against it being more sensible, and automatically not so limited.

So what about

from magic import tell

tell("Banshee").to("lock")

tell("Banshee").Window.to("present)

get("position").from("Banshee").as(int)

Or anything like that!

BeOS’ ‘hey’ command did exactly this with the system’s BMessages, have a look at http://bebits.com/app/3332

Sounds eerily similar to the BeOS's 'hey' application.

hey application verb [ specifier [ of specifier ... ] ] [ to value ]

You could do:

$ hey WebBrowser getsuites

which would give you a list of suites or ontologies supported by the application. Then,

$ hey WebBrowser get title of window

to get the window title for example, or

$ hey StyledEdit set Frame of Window [0] to "BRect(107,76,607,476)"

to move the text editor to a certain position on screen.

Under the BeOS, the hey app was a simple shell command which acted as a front-end to the operating system's BMessage IPC system. Hey could discover custom verbs exported by just about any app.

It's fun to watch ideas that worked well in the 1990s bubbling up into modern OSes.

See http://www.birdhouse.org/beos/bible/bos/ch_scripting6.html#howitworks

remove the black, and you pretty much have Smalltalk syntax.

screensaver lock.

banshee window present.

banshee playerEngine pause.

tomboy createNamedNoteWith: 'My Named Note'

guake addTab.

tomboy onNoteAddedDo: [ banshee playerEngine togglePlaying ].

The next one is very ambiguous. Parsed as English it sounds like playerengine toggleplaying would never happen (because you never stop waiting for noteadded). did you mean "continuously wait for tomboy's noteadded, and tell banshee's playerengine to toggleplaying each time"?

ie:

[ tomboy onNoteAddedDo: [ banshee playerEngine togglePlaying ] ] forever.

6 times do: [ tomboy onNoteAddedDo: [ banshee playerEngine togglePlaying ]]

I've been blown away by some of the amazingly creative and useful things that OS X users have done with AppleScript... by creating a natural-language-like syntax for desktop scripting, you can open up the power of automation (and collaboration around it, one might hope) to an entirely new audience, with different needs and ideas.

Rock ON! :-)

Awesome idea, and this post drove so proud, I get so glad when I see that someone uses Guake :)

Thanks!

While it's cute, I don't think trying to make it look like english is a good idea. It's not english, and will never be. So to use it you still have to learn the syntax, but be carefull of not confusing it with real english. And I'm not even talking about non english-speakers...

I think it's much clearer/easier/shorter/..., if you remove the english :

# tell screensaver to lock

screensaver->lock

# tell banshee’s window to present

banshee.window->present

# tell banshee’s playerengine to pause

banshee.playerengine->pause

# tell tomboy to createnamednote with ‘My Named Note‘

tomboy->createnamednote( ‘My Named Note‘ )

of course for your other examples, it needs some keywords, but I think it's better to keep them to a minimum.

To get return value, I don't think it can get any better than : "name=...", I really don't see what there is to gain by trying to do that with english words.

Ask anyone who have ever tried to parse SQL - and you'll quickly realize that parsing and writing human-readable languages turns out to be a very difficult task.

Dude, ask pretty much any Apple developer and they'll tell you they hate AppleScript. It's one of the rare breed of read-only languages. I suppose it's possible to do it right, but I think it'll require some very, very careful thought, or you have to draw a very clear line to limit what's possible.

Language design is hard and doing something like that, you easily end up where AppleScript is: it's easy to tell what something does, but figuring out what's possible or why something doesn't work is really difficult. I'd seriously consider something with a little stricter syntax even if you feel the current scripting language options aren't good enough.

Awesome stuff!

BUT:

Asking gnome hackers for comments on this is the wrong way to go. They are not really open minded and judge from their perspective as programmers. A lot of comments so far reflect that.

Stick to asking your daughter for feedback.

Mmm

since when I heard about "gnome do"-ifing the entire desktop... I cannot think about Text adventure.

Maybe it's late, but have you looked at http://en.wikipedia.org/wiki/Inform ?

The hard part it's already done (and it's already traslated, if you're interested).

Fantastic! There've been so many times I've wanted something like this!

This is pretty cool.

Although, I'm not sure if I see the benefit of creating a scripting language, as a non-developer, I've been reading about Enso and that kind of thing lately and this seems to have awesome potential to create something similar in Gnome. I'm intrigued by your comment earlier about making it a plugin for Enso: does this imply that Enso is available for Gnome?

This is pretty cool, it could almost be the backend to a conversational interface (CI).

English would go in, then get translated to this simpler intermediate language.

I also think that enso (and mozilla's ubiquity) is the way to go. Due to the similarities between these projects (and yours) a common syntax would be great.

Great idea, and as kragil said, listen to your daughter. By taking to much advice from programmers you'll end up with some half-baked solution which is still to difficult for the regular user that is interested in desktop automation.

Maybe, you should also work with aliases for some of the D-BUS methods to avoid using some really ugly commands.

If this could get integrated into enso or/and gnome-do, it would already be extremely powerfull...

Maybe a way to make it even easier:

Don't rely too much on events .. it would be easier if you could just use the _exact_ menu entries.

tell Firefox to "Open Location..." with www.kryogenix.org

That would even localize more easily.

It should be obvious from every menu and dialog how you can script it.

Is it that way on the Mac?

But you probably will need support from all the app devs for that ;( But it would be SUPER SIMPLE. Don't care for too advanced stuff. This should be for normal people who will not read long docs or APIs or understand programming.

Go for super simple app scripting and stop.

Man, I think of ARexx and how powerfull the AmigaOS really was ... so long ago (nearly 25 year now!). Kinda depressing really ;(

Simon already made most of my point:

If people will appreciate this, they will be drawn in. As human nature is, they will start to try more and more advanced usages, and at some time they will hit the limits of this approach.

If you don't anticipate a smooth migration for more advanced applications, users WILL nag you (just take the comments above ;-). Until you give in and start to add magic for your power users. Magic that won't be easily discoverable for beginners.

Risk is, that, at that point, with your installed base of users, you'll get advanturous, and try to compete with full-blown languages.

IMHO, despite their own calms, most people are proud about any new achievements: Pick them up with something disguised as trivial, BUT make sure they have a steady migration path into mastery of all things ;-).

Good idea (not a great name though :-)

The syntax you're using reminds me of hypercard's "hypertalk" back in the classic Mac days - and that was a great and pretty powerful language, and it's readability was wonderful. May be worth digging into that to see if there's anything there that can be reused.

about storing return results the syntax could be

ask banshee's engine for position store it in position

or something like that, then you can have multiple values.

if you try to keep the languaje and the ideas clean, then it will be a really nice project :)

Looks good to me. I'll be keeping an eye on this one.

Looks great, why not use "and" and "it" to deal with the return value in the same line

e.g:

ask banshee for CurrentUri and print it

This kind of approach is quite old: it looks a lot like Cobol. It has the advantage of being more readable to beginners who are native English speakers than traditional computer languages. But those beginners will quickly learn that far less English is understood than the examples suggest, while non-English speakers will have to memorize a lot of English syntax that isn't relevant to the task. So you're promising flexibility while delivering rigidity.

A non-English speaker is likely to find the Smalltalk-like

screensaver: lock

or

tomboy: createnamednote('My Named Note')

more accessible than the alternatives you provide, because they can just look up the list of actors and methods.

tell screensaver to lock

Great idea.

What about:

uri is CurrentUri from banshee's playerengine

a and b are MultipleResults from Program

In addition to D-Bus perhaps you could also consider issuing commands with the ICCCM and EWMH messages so that you can control your window manager as well.

i.e. tell banshee to maximize.

which would go to metacity or whatever window manager on the users behalf and maximize the banshee window. Not sure how doable it is, just throwing the idea out there is all.

This sounds like an awesome idea to implement and worth pursuing with whatever time that you have. Apple has a GUI to write simple applescripts and are really pushing it. It's called automator I believe. We have shell scripting for the console then why not this automating stuff on the GUI. +1.

As someone who has dabbled in programming but not formally, and someone who considers themselves computer literate but lives in fear of something like a shell script, I think this sounds a good idea, although D-Bus is news to me. Sticking to terminal commands, the problem for non-expert people I think is fear: although "ls -al" is perfectly clear, I would be far more comfortable doing this with more long-winded commands even if the length of the words is the only real difference, e.g.:

"list files -all -long"

or

"list -all files -in_full"

It would be useful to have this as a layer on top of the normal command line. I appreciate these are not good examples.

Although I feel comfortable with some oo programming, I think

tell(”Banshee”).Window.to(”close")

or

banshee.window->close

are way too complicated and abstracted. I think about whether I would like to explain this one of my colleagues who has no experience of programming but who is by no means thick, and I wouldn't bother as I would have to start off with some theory about banshee having properties such as windows then windows having things they can do, including closing, then explain all the punctuation; which is not an English-speakers strongpoint in the "real' world. I might, however, attempt to explain that they could "tell Banshee's window to close" or something. Or, to put it another way, I might feel more comfortable doing this myself, and therefore more in control of my own computer, which is one benefit of Linux/Ubuntu that I really like as it is.

I know I should learn hard-core shell scripting and Python and C and everything to really get everything out of my computer but I think it is missing the point to think that it is an ideal, especially for something like Ubuntu. I sometimes think that programming is the expenditure of a large amount of effort in order to save a little effort. Anything that proves that wrong has to be a good thing.

Awesome work! I remember chatting with people about this very idea, but you're the first person I've seen who's actually Written Some Code. Well played!

- Chris.

If you're really set on a simple language, take advice from someone who has spent years working on this very problem:

SIMPLICITY IS MEASURED IN SIMPLICITY, NOT FAMILIARITY

In other words, sit down and write out a full explanation of your language, and keep revising this explanation and the language itself until the explanation is as short and plain as possible. I think you'll find natural-language syntax, as comforting as it is at first glance, actually adds a lot of unnecessary complexity. As a couple commenters have already mentioned, AppleScript demonstrates that the natural-language syntax approach is a dangerous chimera.

On the other hand, the calls to "just use Python" or to adopt Python syntax are also misguided. Programmers already familiar with Python severly underestimate the complexities of Python syntax and semantics. Even if you're creating a general purpose language, there are much simpler syntaxes than Python.

First, though, you need to decide if your language is really going to be domain-specific. Once you introduce expressions or functions or variables---or all of these things---the language is at that point either a needlessly complex domain-specific language or it's not domain-specific at all.

If you're going to go general-purpose, I can tell you exactly what the simplest possible language to learn looks like: a) all operations and function calls in prefix notation, b) reserved word operators instead ofsymbol operators, and c) Python-style blocks. Here's an example:

function factorial n # function named 'factorial' with one paramenter, 'n'

as val 1 # assign val the value 1

while (gt n 1) # gt = 'greater than'

as val (mul n val) # mul = 'multiply'

as n (sub n 1) # sub = 'subtract'

return val

(factorial 4) # 24

(factorial 5) # 120

It's true that this is not immediately comforting to non-programmers because it contains little English, but the entire language---expressions, variables, identifiers, assignment, if-else-elif, while, operators, functions, recursive functions, globals vs. local scope, lists, dictionaries--takes just over 1 hour to explain in full to total neophytes. (And I should add that the syntax looks better with highlighting.)

But assuming you want to remain domain-specific, you should first address a few issues:

First, you need to clear up whether "tell X to Y" is a call to method Y of instance X or a call to function Y of namespace X. At the very least, if your language requires both method calls and calls from namespaces, these things should have a different syntax because they are conceptually different. (In many languages, like Python, they get confusingly blurred together, both written as x.y())

I'm not familiar with D-bus, but I imagine that, say, 'banshee' in your example was a namespace; if this is the case, I would adopt a syntax like X/Y, where X is the namespace and Y the action:

screensaver/lock

banshee/presentWindow

banshee/playerEngine/pause # playerEngine, a sub-namespace of banshee

tomboy/createNamedNote 'My Named Note' # arguments just listed after the action (with no commas between them)

guake/addTab

If you also have method calls, just make method calls look just like regular function calls but with the instance as the first argument:

banshee/pause playerEngine # playerEngine, a sub-namespace of banshee

(After all, this is really what happens in many OOP languages anyway, like Python.)

As for triggered actions, you need to group statements, so just use Python-style blocks introduced by reserved words:

when tomboy/noteAdded

banshee/playerEngine/togglePlaying

whenever tomboy/noteAdded

banshee/playerEngine/togglePlaying

when 6 tomboy/noteAdded

banshee/playerEngine/togglePlaying

Whatever you do, I strongly suggest dropping the natural-language syntax. The only way to make natural-language work OK is when the user has interactive help as they type, such as in Ubiquity. This works because the user gets immediate feedback about what is legal code, and the code completion means they don't have to remember by themselves when and how to include all the articles and prepositions of English. However, you could get a similar benefit if the user's editing environment gave an explanation in English of what code snippets mean. For instance, if you hover over the line:

screensaver/lock

...you could get some kind of tooltip or status text explaining that this invokes the lock action of the screensaver.

[er, please delete previous, I forgot pre tags]

If you're really set on a simple language, take advice from someone who has spent years working on this very problem:

SIMPLICITY IS MEASURED IN SIMPLICITY, NOT FAMILIARITY

In other words, sit down and write out a full explanation of your language, and keep revising this explanation and the language itself until the explanation is as short and plain as possible. I think you'll find natural-language syntax, as comforting as it is at first glance, actually adds a lot of unnecessary complexity. As a couple commenters have already mentioned, AppleScript demonstrates that the natural-language syntax approach is a dangerous chimera.

On the other hand, the calls to "just use Python" or to adopt Python syntax are also misguided. Programmers already familiar with Python severly underestimate the complexities of Python syntax and semantics. Even if you're creating a general purpose language, there are much simpler syntaxes than Python.

First, though, you need to decide if your language is really going to be domain-specific. Once you introduce expressions or functions or variables---or all of these things---the language is at that point either a needlessly complex domain-specific language or it's not domain-specific at all.

If you're going to go general-purpose, I can tell you exactly what the simplest possible language to learn looks like: a) all operations and function calls in prefix notation, b) reserved word operators instead ofsymbol operators, and c) Python-style blocks. Here's an example:

function factorial n # function named 'factorial' with one paramenter, 'n'

as val 1 # assign val the value 1

while (gt n 1) # gt = 'greater than'

as val (mul n val) # mul = 'multiply'

as n (sub n 1) # sub = 'subtract'

return val

(factorial 4) # 24

(factorial 5) # 120

It's true that this is not immediately comforting to non-programmers because it contains little English, but the entire language---expressions, variables, identifiers, assignment, if-else-elif, while, operators, functions, recursive functions, globals vs. local scope, lists, dictionaries--takes just over 1 hour to explain in full to total neophytes. (And I should add that the syntax looks better with highlighting.)

But assuming you want to remain domain-specific, you should first address a few issues:

First, you need to clear up whether "tell X to Y" is a call to method Y of instance X or a call to function Y of namespace X. At the very least, if your language requires both method calls and calls from namespaces, these things should have a different syntax because they are conceptually different. (In many languages, like Python, they get confusingly blurred together, both written as x.y())

I'm not familiar with D-bus, but I imagine that, say, 'banshee' in your example was a namespace; if this is the case, I would adopt a syntax like X/Y, where X is the namespace and Y the action:

screensaver/lock

banshee/presentWindow

banshee/playerEngine/pause # playerEngine, a sub-namespace of banshee

tomboy/createNamedNote 'My Named Note' # arguments just listed after the action (with no commas between them)

guake/addTab

If you also have method calls, just make method calls look just like regular function calls but with the instance as the first argument:

banshee/pause playerEngine # playerEngine, a sub-namespace of banshee

(After all, this is really what happens in many OOP languages anyway, like Python.)

As for triggered actions, you need to group statements, so just use Python-style blocks introduced by reserved words:

when tomboy/noteAdded

banshee/playerEngine/togglePlaying

whenever tomboy/noteAdded

banshee/playerEngine/togglePlaying

when 6 tomboy/noteAdded

banshee/playerEngine/togglePlaying

Whatever you do, I strongly suggest dropping the natural-language syntax. The only way to make natural-language work OK is when the user has interactive help as they type, such as in Ubiquity. This works because the user gets immediate feedback about what is legal code, and the code completion means they don't have to remember by themselves when and how to include all the articles and prepositions of English. However, you could get a similar benefit if the user's editing environment gave an explanation in English of what code snippets mean. For instance, if you hover over the line:

screensaver/lock

...you could get some kind of tooltip or status text explaining that this invokes the lock action of the screensaver.

I found a few links to HyperTalk and derived languages which you may find useful for ideas:

http://en.wikipedia.org/wiki/HyperTalk

(Note the very readable examples)

Some attempts at hypertalk to javascript compilers:

http://www.creysoft.com/xtalk/

I think this is a great idea, in fact I suggested something similar to ubuntu brainstorms a while back (http://brainstorm.ubuntu.com/idea/15518/). I would wholeheartedly love to help you test when I have the time - plus I think I have a great name for it: "Lingo". (Linux + Go = Language)

[...] still don’t have a decent name for “Linglish”, the toy scripting language for the Linux desktop that I was playing around with a couple of days ago. I’ve added a couple more features to satisfy my curiosity about how hard it would be to do, [...]

Ah crap, ignore my previous post on your new entry about Lingo - D'OH!

[...] Нет ничего особенного в очередном языке программирования «похожем на естественный язык». Забавно тут лишь то, что автор назвал его Linglish. [...]

Brian: There is a big difference between a language that is simple to define and a language that is easy to learn. If the goal is simplicity, than to be sure it is measured by simplicity, but if the goal is a low entry bar, an easy learning curve, than familiarity is important, as is similarity to known methods. You propose using Verb-Subject-Object order because you can easily make a formal definition, and you hope this will make it easier to make clear to new users. But how much time and effort will users need to spend wrapping their mind around the brief definition? How much time will they need to spend teaching their brain the trick of reading fluently in this order?

If the language is targeted at English-speakers, as it clearly is, I strongly encourage the use of Subject-Verb-Object order, just like English. An English-speaker's brain has been optimized to parse in this way. If the language were targeted at, say, Japanese, which uses a different order, then I would recommend using whatever the natural order is for them. Even languages that programmers are accustomed to, like C++, Perl, and Python, use Subject-Verb-Object for simple cases:

myObject.doSomething("withSomething")

myObject is the subject, carrying out the action, while the parameters passed to the method serve (in a basic sense) like objects involved somehow in the action. There is nothing preventing us from doing things like this:

doSomething<-myObject["withSomething"]

doSomething myObject "withSomething"

I'm sure a share of languages like this have been piloted, and as my knowledge is limited, I expect some have met with success, but not the kind of success and general familiarity that has met those that use Subject-Verb-Object. And that is among programmers.

I used reverse polish notation to program for a certain game in late gradeschool (Robowars), when I had already learned some other languages, but while I became capable in it, it was never as comfortable as those other languages. It would have been much easier to formally describe, though.

General:

Hypertalk in its day gathered a much broader fan base than Applescript. The impression I get is that Applescript (and Lingo FWIW) was inspired by Hypertalk, but lost some of what made Hypertalk simple and approachable. Hypertalk was used within a controlled environment, and it basically had no datatypes. Applescript was made a typed language, and it faces the challenge of APIs exposed by multiple applications with different developers and levels of quality. This does sound similar to DSub, although in the open source community quality can sometimes be corrected more easily. However, in Applescript unlike DSub, from long-past experience with Applescript and what I glean about DSub, the only public information about what commands were available was in the structured documentation offered by the app. If DSub links exposure of a command with functionality of that command; if developers aren't in a position to add a command but forget to document it; that might help.

It still is an API in the end though, and a boundless one. I don't know if you can really make it approachable without picking a limited set of applications and commands that you make extremely accessible. A more controlled environment is much easier to make approachable, but also runs the risk of being boring.

Idk if I missed it, but adding support for DBus introspection would be nice, in form of either

look at banshee's window

or

inspect totem's player

would return list of properties and methods the object in question supports.

Also, querying syntax I think could be "ask for totem's window title as t1" - would store totem's window title in variable t1 for later use.

If you don't pretend it's exactly English equivalent, Linglish can be a nice pretty scripting language for fast and easy desktop control (hey, I would like to have a taskbar widget with linglish input line just to impress my non-computer friends by telling various windows to do things).

Linguage? A little bit more generic than Linglish.... But also a word in some languages. Linguo?

[...] GNOME Summit went really well, and I had a great time. One thing that I was really heartened to see is that we’ve agreed on a GLib/dbus plan, and this will enable a number of cool things. First, dbus-glib is just not very good, and we’ve needed a better story. I hadn’t realized before just how much nicer GVariant can make doing DBus calls. But beyond that, having DBus underneath the GTK+ stack will better unlock things like GApplication which will in turn let us do nifty things like exporting GtkAction over the bus. If that’s still a bit abstract, look at say Stuart Langridge’s post on Linglish. [...]