<br>After 4 days reading Nepomuk stuff...<br><br>A tradeof between natural language commands and completely computer oriented language commands will be commands with the following parts:<br><br>- Objects: The information we are working with. Files or text. Objects will always have one or more types. For instance <a href="http://www.kde.org">www.kde.org</a> can be a bookmark and URL and Text. <br>
- Verbs: The actions to be performed. <br>- Modifiers: I think that at least 3 kind of modifiers will be useful:<br>-- Tool (English: with) Example: "open <a href="http://www.kde.org">www.kde.org</a> with firefox" (instead of the default konqueror browser)<br>
-- Source (English: from) <br>-- Sink (English: as, to) Example "save important information here as name_of_file.txt"<br>- Connectors: For instance "and" will take the last command, get the result and use it as the object of the following command.<br>
<br><br>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.<br>
<br><br>Runners:<br><br>-Runners must give more informations about themselves.<br>-- Description: Will be displayed in the future GUI to configure runners (manual ranking, blacklisting, etc.).<br>-- Action or actions the runner provides (the verb of verbs it provides). <br>
-- Type of the object(s) the runner will use.<br>-- If the above object(s) are mandatory or not.<br>-- Modifier or modifiers the runner uses.<br>-- If the above modifier is mandatory or not.<br><br>- 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<br>
<br>- 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. <br>
<br><br><br>Command:<br>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. <br>It has:<br>- Object (QString)<br>- 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. <br>
- Action (QString)<br>- Modifier (QString)<br>- Modifier type. This type is specific to runners (tool, source, sink ...). <br><br><br><br>SearchContext:<br><br>Instead of term(), etc. It gains a QList<Command> with all the possible meanings of the current information.<br>
<br><br><br>RunnerManager:<br><br>- 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.<br><br><br>Krunner/Interface:<br>
<br>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.<br>
<br><br><br>A typical running flow.<br><br>- 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. <br>
<br>- The parsing creates Command objects and add them to SearchContext. <br><br>- The content of each Command can be:<br><br>-- Object : The match operation of enabled runners related to the object is called. This is similar to current behaviour.<br>
-- 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). <br>
-- Modifier: Nothing is done.<br>-- Object Verb: Only call the runner or runners that defines that pair. <br>-- Verb Object: Same than above.<br>-- Any combination of verb object modifier: call runners that define the 3 of them as mandatory.<br>
<br>- 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. <br><br>- The user selects and executes (same than current code).<br>
<br><br><br>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. <br><br><br><br><br><br><br>
<div class="gmail_quote">On Sun, Apr 13, 2008 at 1:08 AM, Jordi Polo <<a href="mailto:mumismo@gmail.com">mumismo@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br><div class="gmail_quote">2008/4/12 Aaron J. Seigo <<a href="mailto:aseigo@kde.org" target="_blank">aseigo@kde.org</a>>:<div class="Ih2E3d"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>On Friday 11 April 2008, Jordi Polo wrote:<br>
> Also, we need extended type information. To put an example, I`ve modified<br>
> (locally) the bookmark runner to also read the bookmarks of krdc and<br>
> konsole. So extra information should be added in the match as for konsole<br>
> bookmarks we surely are interested in konsole --workdir bookmark or browse<br>
> it with dolphin.<br>
<br>
</div>patch?<br>
</blockquote></div><div><br> Unfortunately I am traveling this weekend and don`t have my computer here, I`ll send it on monday.<br><br></div><div class="Ih2E3d"><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
> Aaron suggested some kind of hintting and delaying of hinted runners IIRC.<br>
> That may be a solution that preserve current interfaz but I`d like you to<br>
> consider further changes and get some discussion on the topic now that you<br>
> are meeting.<br>
<br>
</div>could you provide some API examples of wht you are thinking about?<br>
<font color="#888888"></font></blockquote></div><div><br>What I`d suggest is:<br><br>1 - Runners will have a defineType along with the current match and exec methods. <br><br>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. <br>
<br>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.<br><br>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. <br>
<br>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.<br>
</div></div><br> Summary: new method for runners and extended type info. An intermediate step to get the type and distribute the accurate information to the runners. <br><br>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.<br>
<br>So in practice, there will be runners with empty defineType, runners with empty match and exec and runners that define both. <br><br>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.<div>
<div></div><div class="Wj3C7c"><br>
<br clear="all"><br><br>-- <br>Jordi Polo Carres<br>NLP laboratory - NAIST<br><a href="http://www.bahasara.org" target="_blank">http://www.bahasara.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Jordi Polo Carres<br>NLP laboratory - NAIST<br><a href="http://www.bahasara.org">http://www.bahasara.org</a><br>