User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
This will enable remote XUL applications to have spell checking capabilities
without having to run the browser chrome and the user having to install an extention
We will need to stabilize (freeze) the spellchecking API in order for me to
consider it for the toolkit, but I would be excited to do so.
i personally don't like the current spellchecker api's. So i won't be too happy
to see them being frozen.
But making me like the interfaces would require a lot of rewriting, and i don't
know if my ideas of the api are what editor wants. And i currently don't have
time to look into it.
Then we should ask someone what editor wants...
Which spell check API are we talking about?
How big is this? What languages will be included/excluded?
Please also package a spellcheck icon. :-)
Ok, i was a bit confused. The mozISpell* api's look fine. They take a word, and
spellcheck it. Just like it is supposed to do.
It is the nsIEditorSpellcheck that i'm not too happy with. Maybe just because it
lacks documentation :) Or that spellcheck is split between editor and
extension/spellcheck, where the latter implements interfaces defined in editor.
Michiel van Leeuwen (comment 5)--in nsIEditorSpellCheck.idl, there are
CheckCurrentWord and CheckCurrentWordNoSuggest which seem to be what you are
looking for (disclaimer: I've never used any of these apis); is your objection
that you need an editor to initialize the spellchecker?
I think any of the APIs I mentioned earlier will need some cleanup before they
can be frozen.
Yonatan Goraly--as reporter of this bug, can you clarify which (how much?)
spellcheck components you intend?
As a toolkit API driver, I have several related goals:
1) get a simple frozen interface for spellchecking individual words, which is
fully language/locale aware. This part has no UI and would be usable by non-XUL
embedders (i.e. Camino)
2) Specify and freeze core support for spellchecking DOM trees and subtrees,
such as is done by mailnews, NVU, etc. This part would also have no UI and would
be usable by embedders.
3) Add a basic common XUL spellchecking UI that can be hooked up to part 2) and
used by XUL applications with xulrunner.
The code for parts 1) and 2) should live in editor/ (vacate
extensions/spellcheck) and part 3) should live either in editor/ or toolkit/
Does this plan make sense? I'm happy to make this bug a tracking bug, or file
additional bugs about parts 2) and 3). I would like to target parts 1) and 2) at
the 1.9 timeframe, and part 3) at the 1.10 timeframe (although 1.9 would be fine).
Ability to spell check is essential for any business application, makes it
easier for users to adopt.
For the application developer, adding spell check capabilities should be
transparent. Ideally, any text edit element, such as textbox, would have a
spellcheck attribute, when the value is "on" the wrong words would be marked
(with a red line or any other visual cue), and contextual menu could be used to
select alternatives. A less desirable method would be to invoke a spell check
component with the text as a parameter programmatically.
These capabilities should be available both for plain text elements and for HTML
documents in design mode.
Regarding the backend spell API, I think the spell checker should accept
complete sentences or paragraphs, to enable correction of typos that span more
than one word, such as double and.
there are bugs for in line spellchecking and stuff, they'll be fixed eventually,
hopefully they'll be fixed for toolkit.
Benjamin Smedberg (comment 7) --
I agree with part 1 but I do think that api should accept more than individual
words as yonatan goraly points out at the end of comment 8. Ideally the API
could handle thesaurus-like functionality too (but I'm not advocating an
overhaul for that).
I also agree with your 2nd and 3rd parts.
I am fine with vacating extensions/spellcheck. I don't necessarily agree that
the spellcheck components should live in the editor though. If someone wants to
spellcheck something that isn't in an editor, they should be able to, right?
Maybe I need to look more at the existing APIs.
The timeframe is fine with me but it really depends on who is agreeing to do
this work. I haven't seen anyone volunteer to work on any of the 3 parts yet.
For reference. Here are a few open semi random spell checker bugs which might be
of interest. Some of them deal with a "new" API as well: bug 129704, bug 16409,
and bug 119232.
Note bug 302050, which is adding front-end hooks for this to toolkit's textbox binding.