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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ webkit-gtk mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
