Le mercredi 7 août 2013 15:44:52 vous avez écrit : > On Wed, Aug 7, 2013 at 10:13 AM, Aurélien Gâteau <agat...@kde.org> wrote: > > Hi, > > > > I'd like to reach a decision regarding spell checking for QTextEdit. > > > > It was initially a Qt5 task: > > > > "Allow to register a default syntax highlighter type for QTextEdit, the > > KDE > > backend would register the spell checking one coming from sonnet as > > default" > > > > I started working on this task and put together a first patch, but then > > realized it would not be enough: in addition to the syntax highlighter, > > integration with QTextEdit requires context menu support to be able to > > provide > > suggestions for spelling errors. > > > > I already have code which integrates Sonnet (our spellchecker component) > > with > > QTextEdit, in the form of a helper class named (for now) > > Sonnet::TextEditInstaller: > > > > https://git.reviewboard.kde.org/r/111912/ > > > > > > There was a discussion on IRC two days ago regarding how transparent > > should > > spellcheck integration with QTextEdit be, with two possible positions: > > > > > > A. Find a way to inject spellchecking in all QTextEdit through either QPA > > or > > our style. > > > > Pros: > > - Completely transparent to Qt app developers > > - Porting a KDE app to KF5 is only KTextEdit => QTextEdit > > > > Cons: > > - Depends on QPA and/or style, so won't always be available depending on > > the > > platform > > - Could cause problems if spellchecking is injected in QTextEdit where it > > makes no sense to provide this feature (eg. code editor) > > > > > > B. Only provide Sonnet::TextEditInstaller, which app developers would then > > have to explicitly use to add spell checking to QTextEdit in their > > applications. > > > > Pros: > > - No under-the-hood hack > > - Independant from the platform as long as we have Sonnet plugins for it > > - Gives more control to the app developer: for example changing the > > spelling > > language, adding custom words to ignore, or ignoring blocks of text (think > > quoted email) > > > > Cons: > > - Requires developers to explicitly use the API, so porting a KDE app to > > KF5 > > is KTextEdit => QTextEdit + use Sonnet::TextEditInstaller. > > I'm not sure that is a real con. > > KTextEdit still exists in KF5 and has been moved to KTextWidgets in tier 2.
Ohh! I missed that. I assumed KTextEdit was being moved to kde4support, since the Qt task made me think we wanted to add KTextEdit-specific features to QTextEdit. > If I've understood correctly, with option B we would only need to port to > QTextEdit + use Sonnet::TextEditInstaller for anything inside kdelibs tier > 1 and to make it available for any app which only want tier 1 libs. > > Porting any KDE apps can just include KTextWidgets and not change anything > when porting to KF5. This is correct. It may make sense to refactor KTextEdit to use Sonnet::TextEditInstaller to avoid code duplication. Aurélien _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
