of runners, API changes, future and world domination

[Jordi Polo]

After 4 days reading Nepomuk stuff...

A tradeof between natural language commands and completely computer oriented
language commands will be commands with the following parts:

- Objects: The information we are working with. Files or text. Objects will
always have one or more types. For instance www.kde.org can be a bookmark
and URL and Text.
- Verbs: The actions to be performed.
- Modifiers: I think that at least 3 kind of modifiers will be useful:
-- Tool (English: with) Example: "open www.kde.org with firefox" (instead of
the default konqueror browser)
-- Source (English: from)
-- Sink (English: as, to) Example "save  important information here as
name_of_file.txt"
- Connectors: For instance "and" will take the last command, get the result
and use it as the object of the following command.


I've been thinking about how to process the above commands,
multilinguistically, without obvious limitations (they can be processed in
any order) and without complicating too much the current architecture. I'd
like to get your comments on the following changes.


Runners:

-Runners must give more informations about themselves.
-- Description: Will be displayed in the future GUI to configure runners
(manual ranking, blacklisting, etc.).
-- Action or actions the runner provides (the verb of verbs it provides).
-- Type of the object(s) the runner will use.
-- If the above object(s) are mandatory or not.
-- Modifier or modifiers the runner uses.
-- If the above modifier is mandatory or not.

- A new "parse" method (I previously proposed call it "define_types"). See
"A typical running flow" section below. This method will get the information
the user inputs and return 0 or more Commands

- A runner can install its own object types (It is possible to do this in
Nepomuk). So runners can use the infrastructure or if they are very
specific, they can do all the work by themselves: install a new type, its
"parse" method being called so they find their own type and verb and creates
their own matches.



Command:
A new class to define a possible logical parsing of the user input. The
initial parsing of the command line can return 0 or more Command.
It has:
- Object (QString)
- Object type. The type may be based in Nepomuk's Xesam types. I am still
trying to figure out if this is the best approach.
- Action (QString)
- Modifier (QString)
- Modifier type. This type is specific to runners (tool, source, sink ...).



SearchContext:

Instead of term(), etc. It gains a QList<Command> with all the possible
meanings of the current information.



RunnerManager:

- New class to controls what runners will be runnable and some more
functionalities (automatic or manual ranking, etc). See my SoC proposal for
extra information.


Krunner/Interface:

Some functionality will go to RunnerManager. I'd like Krunner become a GUI
for the underlying system, so the system can be used without krunner, just
giving information and asking for results. I still have to think about how
to make that idea a reality.



A typical running flow.

- The user will type or copy some text or ALT+SHIFT+F2 to get clipboard
contents. With changes in the input, the parsing will be invoqued. The
parsing will use the information the runnable runners give to try to define
the type of the objects, actions, modifiers and connectors. It will also
call the "parse" method of the runnable runners.

- The parsing creates Command objects and add them to SearchContext.

- The content of each Command can be:

-- Object : The match operation of enabled runners related to the object is
called. This is similar to current behaviour.
-- Verb : The match operation of runners that define this verb and has no
other mandatory information is called. If an object is mandatory, nothing is
done (maybe autocomplete or other user notification can be given).
-- Modifier: Nothing is done.
-- Object Verb: Only call the runner or runners that defines that pair.
-- Verb Object: Same than above.
-- Any combination of verb object modifier: call runners that define the 3
of them as mandatory.

- All the matches are showed. The ordering of how they are presented to the
user will be controlled depending on the type of objects and preference of
runners.

- The user selects and executes (same than current code).



I am very tempted to start coding all this in playground (copy krunner code
there and modify it) and let the code speak but I guess it is better to
first get a review of the ideas.






On Sun, Apr 13, 2008 at 1:08 AM, Jordi Polo <mumismo at gmail.com> wrote:

>
>
> 2008/4/12 Aaron J. Seigo <aseigo at kde.org>:
>
> > On Friday 11 April 2008, Jordi Polo wrote:
> > > Also, we need extended type information.  To put an example, I`ve
> > modified
> > > (locally) the bookmark runner to also read the bookmarks of krdc and
> > > konsole. So extra information should be added in the match as for
> > konsole
> > > bookmarks we surely are interested in konsole --workdir bookmark  or
> > browse
> > > it with dolphin.
> >
> > patch?
> >
>
>  Unfortunately I am traveling this weekend and don`t have my computer
> here, I`ll send it on monday.
>
>
>
> >
> > > Aaron suggested some kind of hintting and delaying of hinted runners
> > IIRC.
> > > That may be a solution that preserve current interfaz but I`d like you
> > to
> > > consider further changes and get some discussion on the topic now that
> > you
> > > are meeting.
> >
> > could you provide some API examples of wht you are thinking about?
> >
>
> What I`d suggest is:
>
> 1 - Runners will have a defineType along with the current match and exec
> methods.
>
> 2- The current type enum of SearchContext will be extended, possibly with
> types from the ontologies of Nepomuk (it seems  possible and very attractive
> but have to be sure). The type also will need extended information. For
> instance, we got a directory type. But it we need as extended information
> where the type came from. The ranking of the matches may vary depending on
> if the directory was found in the bookmarks of konsole or konqueror.
>
> 3.- In fact, the previous point can be encapsulated in a new class with
> type and data information. SearchContext will have a list of these classes.
> Similar to current SearchMatch.
>
> 4.- As the user inputs text, each runner`s defineType will be called. Some
> runners will have not need to define further. If the runner define or use a
> command, it will add it to the list (saying that the user input has the type
> command). So any command not defined by active and installed runner will not
> be available.  Each runner will add guesses and the extended information to
> the list of types of SearchContext.
>
> 5.- Even when defineType will be called for each runner, I am wondering if
> it would be a good idea let the runners specify what types they are
> interested in so match will be only be called when that types are in the
> list. That will be useful for the future RunnerManagerGUI I guess. Also
> matches can be ordered by type. For instance commands come first, unknown
> type runners` matches come last.
>
>  Summary: new method for runners and extended type info. An intermediate
> step to get the type and distribute the accurate information to the runners.
>
>
> For instance, the bookmark runner will have empty match and exec. As now
> it will search the user input in the bookmarks and find the corresponding
> URL. But it will do it in the defineType method, adding the URL and
> "konqueror as the program the info came from" as information to the list of
> types. The location runners and others will know how to manage that kind of
> information and will not bother parsing.
>
> So in practice, there will be runners with empty defineType, runners with
> empty match and exec and runners that define both.
>
> From monday I`ll take a further look to Nepomuk to dictanimate if it would
> be possible use it or its ontologies for the type field of the information
> the runners work with. IMHO and in the ignorance of the few things I`ve read
> about Nepomuk, it seems a the best approach.
>
>
>
>
> --
> Jordi Polo Carres
> NLP laboratory - NAIST
> http://www.bahasara.org
>



-- 
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/20080416/eeb28ef6/attachment-0001.html