RESOLVED FIXED 97768
Web Inspector: Open resource dialog should assume implicit wildcard in the beginning of the query.
https://bugs.webkit.org/show_bug.cgi?id=97768
Summary Web Inspector: Open resource dialog should assume implicit wildcard in the be...
Vsevolod Vlasov
Reported 2012-09-27 03:16:30 PDT
Patch to follow
Attachments
Patch (5.31 KB, patch)
2012-09-27 03:25 PDT, Vsevolod Vlasov
no flags
Vsevolod Vlasov
Comment 1 2012-09-27 03:25:39 PDT
Build Bot
Comment 2 2012-09-27 04:14:04 PDT
Comment on attachment 165966 [details] Patch Attachment 165966 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/14035778 New failing tests: http/tests/workers/terminate-during-sync-operation.html
Vsevolod Vlasov
Comment 3 2012-09-27 04:39:46 PDT
johnjbarton
Comment 4 2012-09-27 08:56:24 PDT
Yes! Implicit wildcards are a great step in the right direction. With implicit wildcards on the ends, we need only take the next small step and add them between letters. Then we can support queries like "QPanel" when the user has Querypoint.js QuerypointPanel.js Panel.js ScriptPanel.js QuerypointModel.js and so on. Once the user types "Q" the list dramatically and quickly shortens to all things Q, in this case almost exclusively Querypoint*. Rather than tediously typing out "uerypointPa" the user need only add "P" or "Pa" and "enter" to open the file they desire. In general the query and the item list become an interactive selector rather than a static drop down with a static rigid command line. In the place of user total recall and typing we support partial recall and just-enough-typing. The query no longer specifies a selection on a long list, but rather it is a hierarchical, divide and conquer selector where each character divides the list into accept and reject piles. The difference in user performance matches the difference between linear list search algorithms and hierarchical search algorithms.
Vsevolod Vlasov
Comment 5 2012-09-27 09:37:07 PDT
We already support camel case matching, so in your example typing QP should be enough. Do I miss something?
johnjbarton
Comment 6 2012-09-27 09:49:49 PDT
(In reply to comment #5) > We already support camel case matching, so in your example typing QP should be enough. Do I miss something? Sorry my mistake: I meant 'qp' From the list: Querypoint.js QuerypointPanel.js Panel.js ScriptPanel.js QuerypointModel.js The query "qp" gives 0 entries in the current implementation. Why should "QP" be interpreted as "*Q*P*" but "qp" as "*qp*"? What should I expect for "qP" and "Qp"?
Note You need to log in before you can comment on or make changes to this bug.