On Tue, Jan 20, 2015 at 4:05 AM, Carlos Garcia Campos <cgarcia@igalia.com> wrote:<br><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">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?
</div></blockquote><div><br></div><div>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:</div><div><br></div><div>* 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.</div><div><br></div><div>* 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.</div><div><br></div><div>* 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.) </div><div><br></div><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;"><blockquote> (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.)
</blockquote>
Why?</div></blockquote><br><div>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.</div><div><br></div><div>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.</div>