GSoC: command and get obeyed !

[Aaron J. Seigo]

On Tuesday 18 March 2008, Jordi Polo wrote:
> I am studying in the "natural language processing lab" here, so I started
> to get crazy ideas augmented by the "enso" technology video.

cool =)

> I am thinking of a runner for a domain specific language that can be used
> to identify without ambiguity what you want to do with your desktop (at
> least most things).
> Thinks like
> "browse http://www.kde.org"
> "browse http://www.kde.org with konqueror"
> "email panel-kde" -> open kmail, malody, gmail?
> "translate es2en hola" -> use dict plasmoid ?

the first and last one are already possible (well you don't need to 
say "browse", it just does it).

the other two are fairly easy to do as well given the way krunner works.

> To allow this functionality, the language:
> - Must be pretty powerful.  The language should feel  like natural but in
> fact will be pretty limited, surely based in keywords and rules. After the
> summer it can be improved with a upper language level more experimental and
> statistic based.
> - Must be VERY configurable
> - Must be possible to make everything multilingual (surely the biggest
> challenge).

> It surely is better implemented as a plasmoid independent of Krunner.

I'm not sure what you mean here? to me it seems like the perfect candidate for 
one or more AbstractRunner plugins.

> So the project surely implies:
> - A library (plasma engine?) to call the 3 types of resources above
> (already created at least partially?)

that's the role of Plasma::AbstractRunner

> - A definition of the language
> - A configuration facility to let the language map to actions
> and/or
> - A configuration facility for the library (this allows other apps use its
> "get map", etc. Services)

so this is where i think such a project would need to be careful in its 
design:

the way runners work is that each is supposed to be specific to a given 
domain, e.g. web addresses, music collections, applications, etc. the 
benefits are:

* easy to provide access to new domains by writing a AbstractRunner plugin. 
this can be done by a domain specialist, alleviating the need for someone who 
knows everything. you just need to know one domain =)

* the code remains simple for each given domain (one runner -> one job)

* allows the problem to be easily paralellized (a separate execution thread 
for each domain)

* makes it easy to treat each domain separately for categorization, enabling 
or disabling that domain, etc

so a project such as you are proposing should probably not try to 
implement "all possible things" in one runner, but define a language and then 
break the *static* parts of that language into their respective domains 
(writing runners for each) and then provide one "learning" runner that can be 
taught new/arbitrary commands.

since you referenced enzo, let's look at some of its functionality as specific 
examples of domain specific runners:

* window switching commands could go into a WindowRunner
* adding widgets to plasma ("add clock widget") could go into a PlasmaRunner

there is probably some room for pre-match parsing ... e.g. it may be possible 
to define some standardized language for "providing a target". so the 
word "with" could trigger a parsing on "foo with bar" that results in a 
SearchContext that has "bar" as the search term and "foo" as the "verb" to 
apply to it.

this would make "myspreadsheet.ods with kspread" trigger both the ShellRunner 
and the ApplicationsRunner with very little extra code to either one 
(basically just adding "myspreadseet.ods" to the execution)

> Well, I have to formalize all this proposal and also my own information, as
> I said I am learning language processing technologies here and I even have
> a KDE svn account (never used it because of the lack of time), start coding
> should be a matter or learning how to make a plasmoid.

you probably want to look into SearchContext, SearchMatch and AbstractRunner 
in libplasma rather than plasmoids.

> If you don't rule out the idea as too crazy for KDE, I'd try to refine the
> proposal this week and send it.

i look forward to it

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080318/80312d55/attachment-0001.pgp