[webkit-gtk] API for spell check dictionary detection

[Michael Catanzaro]

On Tue, Jan 20, 2015 at 4:05 AM, Carlos Garcia Campos 
<cgarcia at igalia.com> wrote:
> I prefer if the applications do the installation thing, but I see the
> point of making that available for all apps for free by doing it in
> WebKit. And I guess it wouldn't add any dependency because we would 
> use
> DBus to talk to PackageKit. But if we end up doing in in WebKit, I
> wonder if we really need new API for that. Couldn't we check the
> languages when they are set and talk to PackageKit for the ones not
> available?

Yes; in fact, I've already implemented this as a proof of concept. It 
requires no new API (and no new dependencies, since we indeed just talk 
to PackageKit over D-Bus). There are a couple of disadvantages:

* The app has no way to control whether or not the installation is 
attempted. Currently both gnome-packagekit and apper launch a pop-up 
window. We've learned from codec installation that you really ought to 
use a less-obtrusive prompt before opening any dialog or window if it's 
not in reaction to user input. I think it's OK to open a pop-up window 
automatically when the user adds a new language in the preferences 
dialog, for example, but not when simply launches the browser, and 
webkit_web_context_set_spell_checking_languages() will be called in 
both instances.

* There's no way for the browser to know that installation failed (or 
even took place). If installation fails, the browser should update its 
UI somehow and not attempt the install again in the future unless the 
user is modifying his language settings.

* Also, we shouldn't assume the pop-up will be a small window (which is 
annoying enough when we do it for codec installation). Kalev is moving 
this from gnome-packagekit to gnome-software, and we certainly don't 
want to be popping up instances of gnome-software without user 
confirmation. With this in mind, the prompt really should never happen 
automatically. (Related: At the hackfest, I spent a day working on API 
to force browsers to prompt prior to codec installation, but didn't get 
far. Kalev's work is almost done, and if that lands in 3.16 then we 
should completely disable codec installation prior to 2.8, as we can't 
have the browser automatically launching GNOME Software whenever the 
user visits a page with video or audio he can't play.)

>>  (You have definitely convinced me that my original proposal,
>>  webkit_web_context_get_available_spell_checking_languages(), is not 
>> a
>>  good idea -- at least not on its own.)
> 
> Why?

If the app does not allow the user to install new dictionaries, then 
you're right, 
webkit_web_context_get_available_spell_checking_languages() would be 
useful. But it's safe to say that for users who know a language other 
than English, it won't be possible to get spell checking working for 
these apps without manually installing a package, which is something I 
think we should discourage. Also, this model doesn't work if the app 
wants to use the same list of languages for HTTP headers as it does for 
spell checking, like we do in Epiphany, since we shouldn't restrict the 
list of possible languages for HTTP headers to those with dictionaries 
installed.

If the app does allow the user to install new dictionaries, then 
webkit_web_context_get_available_spell_checking_languages() is less 
useful (at least without other API to install dictionaries). Such an 
app must understand the paths at which dictionaries for at least one 
Enchant backend can be found in order to install them, so it might as 
well check those paths to determine if the dictionaries exist. The 
advantage of the API is that it will automatically check *all* Enchant 
backends for dictionaries, whereas the app will probably just check one 
(for Epiphany, I think only hunspell is worth supporting), so the API 
would allow the browser to e.g. skip installing a hunspell dictionary 
if an ispell dictionary is already available for that language.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-gtk/attachments/20150120/314c45b7/attachment-0001.html>