Hi again. So, based on this list, I made a 12 week plan for the project based on the 12 week scheme used in GSoC:
Week 1/2: Tweak Nepomuk runner Week 2/3: Tweak File search runner Week 3: Tweak Google runner Weeks 4 to 5 (or 6?): Put result querying in a different thread Week 6: Polish what has been done so far Week 7: Get user feedback better (Tell when searching and when nothing was found, some helping message at start) Week 8: Separate results in groups, allow user to define the priority of each runner (or allow developer to define the priority each one of their runner's commands can set it) Week 9: Make results fit on only one krunner screen, shrink less relevant results, hide lesser relevant results on main krunner screen Week 10: Expanding/unexpanding search groups Week 11: Extra actions for each item of the results, depending on its type Week 12: Polish and get everything ready to go What do you think? Em 1 de maio de 2011 04:06, Luiz Romário Santana Rios <luizroma...@gmail.com > escreveu: > Ah, this is not a definitive list. We can add/remove stuff from it. > > Em 1 de maio de 2011 04:04, Luiz Romário Santana Rios < > luizroma...@gmail.com> escreveu: > > Take a look at this and see if it's OK: >> >> Improve krunner result displaying brainstorm: >> + Tweak runners result rating >> * Nepomuk runner >> ~ Remove over and over repeated results >> * File search runner >> Priority criteria >> ~ Exact match: for "photos", priorize "Photos" over "Photos - >> september", for example >> ~ Priorize folders over files >> ~ Folders that contain several folders or files that match the query, >> probably showing them as "subresults" >> * Google runner >> ~ Show a list of actual results from the search (Is this possible?) >> + Change krunner result displaying >> * Group each runner results into its own category >> * Allow user to change the categories' priorities (For example: first, >> commands, then, files, then, nepomuk, etc....). >> * Show as many results as it fits in krunner, shrinking the less >> relevant ones. (configurable) >> * If there are results from more than a runner, give the user an option >> to expand one category and show only its results. >> ~ Show further results in the associated application >> * Show extra actions for each item >> * Give the option of using a compact layout >> * Mockup: >> https://picasaweb.google.com/luizromario/Mockups#5601639496208873426 >> + Fine-tune krunner >> * Popup some helping text if user waits too long >> * Tell the user when krunner is searching and when it found nothing >> * Put query in a different thread so krunner doesn't freeze while the >> user is typing something (if it still isn't). >> >> And I think the KSysGuard part it uses needs some care too. >> >> Anyway, sorry for taking so long, I got stuck sometimes when doing this. >> >> 2011/4/30 Aaron J. Seigo <ase...@kde.org> >> >> On Friday, April 29, 2011 23:57:57 Luiz Romário Santana Rios wrote: >>> > 2011/4/29 Aaron J. Seigo <ase...@kde.org> >>> > >>> > > On Friday, April 29, 2011 00:21:11 Luiz Romário Santana Rios wrote: >>> > > > 2011/4/28 Aaron J. Seigo <ase...@kde.org> >>> > > > >>> > > > > On Thursday, April 28, 2011 09:15:08 Luiz Romário Santana Rios >>> wrote: >>> > > > > > Currently, when we type something in, krunner displays the >>> > > > > > results >>> > > > > > as it finds it, without giving a feedback of whether it is >>> > > > > > searching or just didn't find anything. >>> > > > > >>> > > > > that would be a nice addition. >>> > > > > >>> > > > > > It also does not separate the results into its different >>> > > > > > categories >>> > > > > >>> > > > > that's because they are organized by relevance. if they are >>> > > > > sorted into categories, and if there are 4 categories that >>> > > > > match and 5 items in >>> > > >>> > > each >>> > > >>> > > > > category then the best match from the 4th category will be the >>> > > > > 16th >>> > > >>> > > item >>> > > >>> > > > > in the list(!) even though it is more likely to be what the user >>> > > > > wants than most >>> > > > > of the items above it. >>> > > > > >>> > > > > i have yet to see a solution for this problem, but am open to >>> > > > > such a >>> > > > > solution >>> > > > > being offered. >>> > > > >>> > > > Well, I thought about showing only the most relevant results for >>> > > > each >>> > > > category and priorizing the category with the most relevant >>> results. >>> > > > If a >>> > > >>> > > which is almost always going to be the nepomuk search ;) >>> > > >>> > > > user want to see more results for that category, they would just >>> > > > need to expand it. I'll do some mockups for that and will post >>> > > > here. >>> > > >>> > > sounds good; mockups always help. >>> > >>> > Here's one: >>> > >>> http://lh5.googleusercontent.com/_V8ZPvFyTxNc/Tbty2kU7CII/AAAAAAAAARs/v_Ut1J >>> > 8P4DQ/01%20-%20Expand%20and%20Shrink%20less%20relevant%20results.png >>> > >>> > It's bad, I know, I suck at making mockups, but it gives part of the >>> idea of >>> > what I mean. >>> >>> wire frame mockups like that one are just fine. they let one concentrate >>> on >>> the structure rather than get distracted by shiny things ;) >>> >>> > Notice that I show two different ways of expanding the results >>> > in it. I think the button is better, but it takes too much space, so >>> I'm >>> >>> and what would be the workflow to expand / collapse / run? >> >> >>> an important part of krunner is being able to very quickly type and >>> execute. >>> the UI is not fancy, but it is designed for speed. >>> >> >> See mockup in the beginning of the message. But, basically, running >> anything by just typing and hitting enter wouldn't change much. >> >> >>> >>> > > then the Nepomuk runner needs tweaking in how it rates results. >>> > >>> > So this is the first thing we should do, I guess. >>> >>> it's definitely a good starting point. :) >>> >>> > What I meant was that I think it's better to wait one or two seconds >>> after >>> > the user stops typing so that krunner doesn't start querying with an >>> > incomplete string. >>> >>> that would probably ruin one of the main features of krunner: match as >>> you >>> type. >>> >> >> Yeah, you're right. >> >> >>> >>> > I also think it would give focus to the main result, if >>> > there's one, but I may be wrong. >>> >>> it already does. >>> >>> > Weird. Should it work if I just type in something and then press the >>> down >>> > arrow? >>> >>> yes... >>> >>> > Well, I will stop and think over this project and get back with better >>> > summarized idead and more mockups tomorrow. >>> >>> :) >>> >> >> See above. :) >> >> >>> >>> -- >>> >>> 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 Qt Development Frameworks >>> >>> _______________________________________________ >>> Plasma-devel mailing list >>> Plasma-devel@kde.org >>> https://mail.kde.org/mailman/listinfo/plasma-devel >>> >>> -- >> Luiz Romário Santana Rios >> > > > > -- > Luiz Romário Santana Rios -- Luiz Romário Santana Rios
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel