[webkit-dev] Spelling document markers: Design question

[Hajime Morrita]

On Tue, Mar 12, 2013 at 6:48 AM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> Thanks for the clarification.
>
> On Mon, Mar 11, 2013 at 9:35 AM, Rouslan Solomakhin <
> rouslan+webkit at chromium.org> wrote:
>
>> On Sun, Mar 10, 2013 at 10:47 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>>
>>> On Thu, Mar 7, 2013 at 2:58 PM, Rouslan Solomakhin <
>>> rouslan+webkit at chromium.org> wrote:
>>>
>>>> The contextual spellcheck in Chromium needs to identify the spellcheck
>>>> request that added spelling markers to the document.
>>>>
>>>
>>> What is contextual spellcheck?
>>>
>>
>> Contextual spellcheck in Chromium takes a sentence like "The duck says
>> quick" and marks the word "quick" as contextually misspelled. The
>> spellcheck would suggest "quack" instead of "quick". Although all words are
>> spelled correctly, the word "quick" makes less sense than "quack" in the
>> context of that sentence.
>>
>>
>>> This information will be used to provide a feedback loop to the
>>>> contextial spellcheck. I was thinking about adding an ID field to
>>>> DocumentMarkerDescription detail. Is this a correct approach?
>>>>
>>>
>>> I'm with morrita on this one but it's hard to answer this kind of a
>>> design question without understanding what you're trying to achieve.
>>>
>>
>> What we're trying to achieve is provide a feedback loop for the
>> spellcheck, so it can improve the suggestions over time. For the feedback
>> loop to work, we're going to assign unique identifiers to spellcheck
>> results and store the identifiers in markers. When the user performs any
>> operation on a spellcheck marker, the identifier from the marker will be
>> used in the feedback. User operations may include "Add to dictionary",
>> "Always ignore", "Select suggestion X", etc.
>>
>
> That sounds like a useful feature in general.
>
> On Mon, Mar 11, 2013 at 9:41 AM, Rouslan Solomakhin <
> rouslan+webkit at chromium.org> wrote:
>
> On Sun, Mar 10, 2013 at 10:40 PM, Hajime Morrita <morrita at chromium.org>
>>  wrote:
>>
>>> There are DocumentMarker, or DocumentMakerDetails. Which do you have in
>>> your mind?
>>>
>>
>> I had DocumentMarkerDetails in mind. It seems to be the standard location
>> of auxiliary information for a document marker.
>>
>>
>>> Or you can possibly introduce another DocumentMakerDetails for the
>>> "contextual  marker". This approach might be cleaner. By introducing the
>>> new subclass, it won't interfere existing marker implementations. One
>>> caveat of this approach is that this needs extra heap allocations since
>>> DocumentMarkerDetails with unique IDs cannot be shared and will be
>>> allocated per marker.
>>>
>>
>> I like the approach with another DocumentMarkerDetails class. I would
>> like to have both description and identifier in my DocumentMarkerDetails.
>> Would it be OK to inherit from DocumentMarkerDescription?
>>
>
> I'd rather not add another subclass. That's even worse than
> modifying DocumentMarkerDetails IMO because this new subclass
> of DocumentMarkerDetails can't be shared among multiple markers.
>

> It seems okay for each DocumentMarker to directly have an identifier
> although we might want to if-def it depending on how big that identifier is.
>

On the other hand, if the ID is assigned per spellcheck request, not per
word, it can be shared in the requested sentence. So the overhead won't
that big. Also, API surface on DocumentMarkerController will be suffered by
the change, especially if we ifdef it. Considering that the contextual
spell checking (not grammatical checking) is virtually a chromium only
feature, it might be better to let the complexity cost small by just
extending DocumentMarkerDetails.

I'm fine with either way though. There isn't big difference here.


> - R. Niwa
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130312/d3aba007/attachment.html>