GSoC: command and get obeyed !

[Jordi Polo]

Rereading this message, please understand that all I am talking about is
about a fast interface that does not need mouse picking the correct choice.

I was very concentrated thinking about this problem (in the toilet, you know
...) and had a thought both trivial and illuminating.
Even if they may seem the same the following two are very different cases:
- http://whatever
- =2+2

In the first case, we have _plain text_ that happens to be an URL
In the second case, we have a _domain specific language_ '=' is not likely
to be found in most document in that position.

I think both are really cool and both have very good uses not only in
krunner but for the desktop.
The main advantage of the first approach (other than less typing) is that
anything becomes krunnable, any konqueror word, any Localizer sentence, any
equation.
To achieve it we just need a shortcut that runs krunner in whatever you last
put in your clipboard and launch the most relevant action. Even the
applications can give tips to krunner to choose the runner?
And Imagine a shortcut that do the above and takes the information back to
your application (maybe this can be managed with drag and drop or something
similar and get a lot of power with little effort).
Also is the way to go if you don't know the commands.

The main advantage of the second approach is that it lets you make complex
things with a very natural interface and in an unified way all over the
desktop.
"translate"
"map"
"send to bugs at kde.org"
"svn up"

All those commands will be applied again to the last thing you entered in
the clipboard (or run them in Krunner as "command data")
It will be very possible but not so general to select the word "Madrid" (or
write it in krunner) and get the top rank runner a map service runner.
And almost imposible get the translation service in the first place given
any general word.
So commands can specify!

I argue that both modes (plain text and command line) are useful not only in
krunner but beyond.
But they must be differentiate (you may want to look for the word
"translate" in your HD).
The fastest thing I can think is using an special character like ':' or '='
that will not be likely to appear in a natural text at the beginning of a
sentence.
So:
translate  -> feed runners and get their results (the user select or launch
the top ranking)
:translate -> The command is parser and only the "translate" service runner
is called

I hope all this make sense for you as it does for me and see how the big
picture can make it a really powerful feature in KDE. I think that at least
the krunner and runners work is attainable in one SoC. Using it in
applications ... You know better than me how hard it can become.

Please let me know your thoughts. Sorry for the horrible long email... I may
be too verbose explaining myself ...



2008/3/19 Aaron J. Seigo <aseigo at kde.org>:

> On Tuesday 18 March 2008, Jordi Polo wrote:
> > If you write:
> > http://www.domain.com
> > Surely you want to open a browser with that
> > But it will be possible (if it is not working yet) that the files
> > downloaded from internet are annotated with the page from where they
> were
> > downloaded. Then you may mean search for that in your metainformation.
>
> which is one reason we have relevancy ranking and the ability to have
> multiple
> returns.
>
> > So, what I thought was create domain specific runners as you said (the
> > current swith user, logout, etc. Functionality is a good example) and a
> > language to avoid ambiguities. ("search  2+2"  or "calc 2+2" for
> instance).
>
> the calc runner actually use '=' to denote a calculation. so 2+2 won't
> produce
> a calculation, but =2+2 will. so we're mostly on the same page here. we
> could
> easily add "calc" to it the calc runner if we wanted, of course =)
>
> but yes, i agree with the concept.
>
> that said, krunner supports the idea of multiple answers, so even if you
> got
> two returns it's also ok. being able to rank them properly is pretty
> important, of course.
>
> > Also, it can be a good idea to make the commands eventually produce
> > information that could be inserted in other applications.
>
> the translation runner sort of does this already, actually, by putting its
> answer into the clipboard when selected.
>
> > But the "parse high level language and give the parsed information to
> one
> > domain specific runner" is pretty different and I'd say that even
> > incompatible with the "give the info to the runners and get the results"
> > that I think is how the current krunner works.
>
> i'm not sure i follow you here.
>
> there are two places the parsing can happen:
>
> * in individual runners
> * before hitting the runners
>
> if the latter, that just means we need to expose another data structure in
> addition to the raw search term to runners that care that contains the
> results of the parsing.
>
> --
> 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
>
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>
>


-- 
Jordi Polo Carres
NLP laboratory - NAIST
http://www.bahasara.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20080319/3fc580e9/attachment.html