[webkit-gtk] WebKit 2 search API proposal

[Žan Doberšek]

I think the 'find client' should definitely be tied to WebKitWebView, but
should not be settable. Ergo, only one instance of 'find client' would
exist per a web view. In the current proposed API by Sergio, the 'find
client' object doesn't have any user-definable properties that would
require resetting the that object as the 'find client' of the web view in
which the search would be performed.

I've been writing 'find client' because I don't really like the name. Using
the word 'find' sounds to me as there's a guarantee that something would be
found. This honestly is just nitpickish, but it simply sounds wrong in my
ears. I'd propose using the name 'WebKitTextSearchClient'. I'd leave the
'text' part in the name just so that people would not be confused about
thinking that they can perhaps perform googling or something similar.

The search client would then offer the signals as originally proposed.

Is there any interest of also providing a list of matches? That way
something similar to what Chromium is doing could be done (showing the
matches in the scrollbar). Though, other than that, I can't think of an use
case. Also, _next() and _prev() would be good additions to the API in that
sense.

Regards,
Zan

On Mon, Dec 26, 2011 at 2:17 PM, Carlos Garcia Campos <cgarcia at igalia.com>wrote:

> El lun, 26-12-2011 a las 13:40 +0100, Sergio Villar Senin escribió:
> > I'll start reviewing the current WK1 API and how it's being used and
> > then I'll discuss the proposal for WK2 (some of the ideas come from
> > talks with Carlos a couple of weeks ago).
> >
> > * Current status
> >
> > Both epy and devhelp use the WK1 search API the same way. Whenever
> > search function is enabled they both perform
> >
> > webkit_web_view_unmark_text_matches();
> > webkit_web_view_mark_text_matches();
> > webkit_web_view_set_highlight_text_matches(TRUE);
> >
> > In order to perform a search clients typically do:
> >
> > webkit_web_view_search_text()
> >
> > they are forced to store the text to be found in order to be able to
> > call search forward or search backward, something that IMO it's a bit
> > weird because by one side the API remembers the state of the search but
> > by the other side the client always have to provide the text to search.
> >
> > Finally when find toolbars are closed
> > webkit_web_view_set_highlight_text_matches(FALSE) is called.
> >
> > Personally I find also a bit weird to force clients to do
> > unmark+mark+set_hightlight always, as that should be the default action
> > anyone could expect when searching.
> >
> > * Proposal
> >
> > - Implement a WebKitWebFindClient which would be a separate object
> > returned by the web view. I removed the "_text" suffix from the API as
> > it should be pretty clear that we're searching for text. The find client
> > will store the text to be search removing that responsibility from the
> > caller. I also added the next() and prev() methods that seem to be
> > pretty common.
> >
> > - WebKitWebFindClient webkit_web_view_get_find_client()
> > - void webkit_web_view_get_find_client(WebKitWebFindClient)
>
> I guess this would be set_find_client.
>
> I would avoid using FindClient this way, we are indeed removing
> LoaderClient object. I like the idea of using a separate object, but I
> would do something similar to the downloads API.
>
> WebKitSearch *webkit_web_view_search(view, string, flags);
>
> WebKitSearch object would be your FindClient object, but it's created on
> demand for every search.
>
> > - webkit_web_find_client_search (string, flags)
> >  + signals
> >    + found-string(string, match_count)
> >    + find-error(string)
> >    + matches-count(string, match_count)
>
> The string is stored in the WebKitSearch/FindClient object, so we
> shouldn't need to pass it on every signal, we could add API to get if
> needed from the callbacks.
>
> > - webkit_web_find_client_search_next()
> > - webkit_web_find_client_search_prev()
> >
> > Opinions?
>
> --
> Carlos Garcia Campos
> http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
>
> _______________________________________________
> webkit-gtk mailing list
> webkit-gtk at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-gtk/attachments/20111226/af224249/attachment.html>