RESOLVED INVALID 66812
[Qt] Spell check platform plugin API enhancement
https://bugs.webkit.org/show_bug.cgi?id=66812
Summary [Qt] Spell check platform plugin API enhancement
Dawit A.
Reported 2011-08-23 14:22:55 PDT
Add several missing functions to the newly create spelling and grammar check platform plugin.
Attachments
proposed patch (7.66 KB, patch)
2011-08-23 14:27 PDT, Dawit A.
no flags
proposed patch II (7.18 KB, patch)
2011-08-30 12:05 PDT, Dawit A.
no flags
Dawit A.
Comment 1 2011-08-23 14:27:12 PDT
Created attachment 104917 [details] proposed patch
Benjamin Poulain
Comment 2 2011-08-30 11:43:06 PDT
Comment on attachment 104917 [details] proposed patch View in context: https://bugs.webkit.org/attachment.cgi?id=104917&action=review > Source/WebKit/qt/WebCoreSupport/TextCheckerClientQt.cpp:55 > - m_spellChecker->ignoreWordInSpellDocument(word); > + m_spellChecker->ignoreWord(word); I think a mapping 1 to 1 between the WebKit APIs and the platform plugin is a good thing. Platform plugins are a low level tool for us, it does not needs a beautiful API, it needs a totally unambiguous API.
Dawit A.
Comment 3 2011-08-30 12:03:02 PDT
(In reply to comment #2) > (From update of attachment 104917 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=104917&action=review > > > Source/WebKit/qt/WebCoreSupport/TextCheckerClientQt.cpp:55 > > - m_spellChecker->ignoreWordInSpellDocument(word); > > + m_spellChecker->ignoreWord(word); > > I think a mapping 1 to 1 between the WebKit APIs and the platform plugin is a good thing. Platform plugins are a low level tool for us, it does not needs a beautiful API, it needs a totally unambiguous API. Ok. Will revert.
Dawit A.
Comment 4 2011-08-30 12:05:06 PDT
Created attachment 105663 [details] proposed patch II Reverted back "ignoreWord" to "ignoreWordInSpellDocument" in QWebSpellChecker.
Benjamin Poulain
Comment 5 2011-08-30 13:17:43 PDT
Comment on attachment 105663 [details] proposed patch II I am not even convinced that should be part of the same plugin. This is a lot more intrusive than the text checker patch, not sure how do deal with that really.
Allan Sandfeld Jensen
Comment 6 2012-08-22 15:40:46 PDT
The patch looks good to me, but will need a rebase for a new review.
Simon Hausmann
Comment 7 2012-08-29 11:46:16 PDT
(In reply to comment #6) > The patch looks good to me, but will need a rebase for a new review. You're right, the patch is rather clean. I think it's missing a best a version update of the platform plugin interface version string because of the API changes. But there's one thing I'm not sure if I understand correctly: How does the UI for this look like? Does the platform plugin pop up a modal dialog? Is there any way for the application / browser to affect the appearance of this? How does it look like in other browsers? Is this still relevant? :)
Lindsay Mathieson
Comment 8 2012-08-29 14:27:14 PDT
Its a platform plugin framework, it doesn't have a UI or even spellcheck capability of its own. The Applications using it supply the plugin implementation and UI.
Simon Hausmann
Comment 9 2012-08-29 22:24:06 PDT
(In reply to comment #8) > Its a platform plugin framework, it doesn't have a UI or even spellcheck capability of its own. The Applications using it supply the plugin implementation and UI. The interface added with this patch appears to delegate the responsibility of showing a spell-checking UI (dialog) to the platform plugin. The platform plugin on the other hand is designed to be supplied by the platform (KDE, or for example the Nokia N9 using MeeGo is shipping one such plugin), not the application. In fact there is no application side interface to supply the platform plugin.
Lindsay Mathieson
Comment 10 2012-08-29 22:33:31 PDT
(In reply to comment #9) > (In reply to comment #8) > > The interface added with this patch appears to delegate the responsibility of showing a spell-checking UI (dialog) to the platform plugin. Yes. > > The platform plugin on the other hand is designed to be supplied by the platform (KDE, or for example the Nokia N9 using MeeGo is shipping one such plugin), not the application. In fact there is no application side interface to supply the platform plugin. I wasn't under that impression, I thought Platform Plugin meant plugins that were platform dependent (as in KDE, Pure Qt, Meego etc), but implemented by the application either dynamically or statically. Why else have explicit support for static plugins which can only be implemented by applications.
Simon Hausmann
Comment 11 2012-08-30 01:00:03 PDT
(In reply to comment #10) > > The platform plugin on the other hand is designed to be supplied by the platform (KDE, or for example the Nokia N9 using MeeGo is shipping one such plugin), not the application. In fact there is no application side interface to supply the platform plugin. > > I wasn't under that impression, I thought Platform Plugin meant plugins that were platform dependent (as in KDE, Pure Qt, Meego etc), but implemented by the application either dynamically or statically. Why else have explicit support for static plugins which can only be implemented by applications. That's unfortunately not the case. The mechanism for loading the platform plugin expects to find it in the system wide library directory, to be loaded dynamically at run-time. It does not support statically linked platform plugins and applications are not supposed to install libraries into those system locations (because they would affect other unrelated applications). The platform plugin - like the name says - is supposed to be provided by the platform, the entity distribution Qt usually. This is why I'm concerned that this may not be the right approach to implementing / delegating the UI of spell checking.
Lindsay Mathieson
Comment 12 2012-08-30 06:11:38 PDT
(In reply to comment #11) > > That's unfortunately not the case. The mechanism for loading the platform plugin expects to find it in the system wide library directory, to be loaded dynamically at run-time. It does not support statically linked platform plugins and applications are not supposed to install libraries into those system locations (because they would affect other unrelated applications). It most definitely does load static plugins - for a start off I'm testing with them. Also see "bool QtPlatformPlugin::loadStaticallyLinkedPlugin()" in QPlatformPlugin.cpp. Also it loads dynamic plugins from QCoreApplication::libraryPaths() + "/webkit/" which as per the Qt Docs: "This list will include the installation directory for plugins if it exists (the default installation directory for plugins is INSTALL/plugins, where INSTALL is the directory where Qt was installed). The directory of the application executable (NOT the working directory) is always added, as well as the colon separated entries of the QT_PLUGIN_PATH environment variable." > > The platform plugin - like the name says - is supposed to be provided by the platform, the entity distribution Qt usually. I disagree - to me platform plugins are specific to the platform but not neccessarily provided by it. The inline spell plugin is a good example, in KDE its far more useful for it to be customised per app then to be a single global item.
Anders Carlsson
Comment 13 2013-10-02 21:13:38 PDT
Comment on attachment 105663 [details] proposed patch II Qt has been removed, clearing review flags.
Jocelyn Turcotte
Comment 14 2014-02-03 03:18:43 PST
=== Bulk closing of Qt bugs === If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary. If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.
Note You need to log in before you can comment on or make changes to this bug.