[GCompris-devel] Search feature

Bruno Coudoin bruno.coudoin at gcompris.net
Mon Jan 4 21:54:05 UTC 2016



Le 04/01/2016 20:22, RISHABH GUPTA a écrit :
>
>
> On Mon, Jan 4, 2016 at 12:35 AM, Bruno Coudoin
> <bruno.coudoin at gcompris.net <mailto:bruno.coudoin at gcompris.net>> wrote:
>
>
>
>     Le 03/01/2016 19:34, Aruna S a écrit :
>>     Hey Rishabh!
>>
>>     The search feature is much needed, so it'll be great to have you
>>     work on this.
>>
>>>         The only thing I have figured out is to use a hash table
>>>         since it provides a faster lookup .I would  need little
>>>         guidance and input from all of you to complete it. 
>>
>>     A simple and quick way to implement a hash lookup in Javascript
>>     would be to create a searchable JSON object where the keys and
>>     values in the JSON object pertain to each activity.
>>     The key would have to be unique for each activity(the name of the
>>     activity? Or a hash of the activity code or some other way), and
>>     the value of the key has to be a way to bring the activity to the
>>     forefront.
>     Hi, I am not convince we need to maintain a hash for faster
>     lookup. I made the following test using grep:
>
>     time grep -i mouse src/activities/*/ActivityInfo.qml
>     0,00s user 0,00s system 0% cpu 0,003 total
>
>     So it take 3ms to get the list of all activities containing the
>     word mouse in upper or lower case. No big deal. We may have a
>     worse result in javascript but doing so in C++ would get us to
>     close results.
>
>>
>>     Not sure if this solution is the best one, but a brute force way
>>     to present games that match a search query might be to create an
>>     invisible section(like the favourites, maths, strategy section
>>     etc) to present the matches from a search query, and add this
>>     section name to the ActivityInfo.qml. The section can be made
>>     visible/active only when a "Search" is in progress and is
>>     presenting results.
>
>     I like the concept. Just going further on it I propose something
>     along these lines:
>
>     - there is a search icon in the section list (top rigth in
>     horizontal mode).
>     - when clicked the section icons are replaced by a search entry
>     box (and a virtual keyboard appears if needed)
>
>
>
>
> In my opinion instead of having the search icon on the top right we
> can place it on the bottom next to configuration icon . 
> - On clicking it the icon would expand into a search entry box .
This is a good idea but I prefer to have it in the section bar. The
section bar is the logical place to filter activities, it is done for this.
>
>
>  
>
>     - the search is done incrementally, uppon each letter entry a
>     'grep' is performed and the list of matching activity is shown
>
>
>
> if for every letter a matching activity is to be shown then we cannot
> use hash table.
Another reason not to have one.
> -We can store activities by their name in a QList ,this would allow to
> display all the activities matching every letter the user types.
This is what we do at the moment in ActivityInfoTree.cpp to manage tags.
The new filtering is just an added feature to the current system,
nothing more.
>
>  
>
>     - when we get back from an activity we are again in thesame search
>     if we started the activity from here
>     - a 'stop search' icon allows to get back to the normal mode
>
>      
>
>     Bruno.
>
>
> Also how should  I debug qml files  ?like setting breakpoints
> ,stepping  etc .? is there any way to do that?
I used it once when I started Qt Quick and saw the debugger working in
javascript files but last time I tried it was not working. I just do it
old school by putting debug traces with console.log().
>
> thank you all for your inputs  :)
Your welcome.

Bruno.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/gcompris-devel/attachments/20160104/1b77407c/attachment.html>


More information about the GCompris-devel mailing list