Re: MacOSX builtin spellcheck support

Here ! It now work. The project build a appleSpell.dylib ( that can be
renamed to .so so enchant finds it )
those trying to build this should modify the target to the right path
to their libglib.

Le 04-10-08, à 16:04, R. Payette a écrit :

> ok... I have a start of an enchant pluggin for appleSpell but i'm
> stuck and need a little help...
>
> The pluggin build and load. The enchant -a in the test directory of
> enchant return this :
>
> enchant[18135] 1 (null) exist ? 0
> enchant[18135] AppleSpellChecker::requestDictionary en, 0x0
> enchant[18135] AppleSpellChecker::~AppleSpellChecker
> Couldn't create a dictionary for en
> enchant[18135] appleSpell_provider_dispose
>
> the first line being the result of
> NSLog(@"%d %@ exist ? %d",, m_tag,[[NSSpellChecker
> sharedSpellChecker]language], [NSSpellChecker
> sharedSpellCheckerExists]);
>
> so as I understand it, the spell checker is not available to
> libraries, only applications. Someone as an idea how to get around
> this ? Apple documentation is not very helpful on this.
>
>
>
> <sasa.tgz>
>
>
>
> Le 04-10-07, à 21:12, Dom Lachowicz a écrit :
>
>>
>> Hi Remi,
>>
>>> Is it really necessary to have yet another
>>> abstraction layer over the
>>> dictionaries ? What enchant does it basically the
>>> same thing that
>>> AppleSpell already does : control dictionary
>>> backends. Wouldn't it be
>>> overkill to have ispell running under AppleSpell
>>> running under Enchant
>>> which, through a SpellChecker subclass talk to the
>>> SpellManager which
>>> provide abiword with spelling service ? And a user
>>> having already
>>> ispell installed on their mac could download an
>>> abiword binary with
>>> enchant enable and having a second ispell running
>>> under enchant.
>>
>> Yes, it is essential for "yet another abstraction
>> layer". AbiWord is a cross-platform product. Yet we
>> want to integrate as best as possible with the native
>> OS.
>>
>> AbiWord on Mac should probably never ship with Ispell
>> as its spellchecker. Since we already require glib, we
>> should use Enchant, especially if Enchant can take
>> advantage of builtin MacOSX Services like the
>> AppleSpell service.
>>
>> In the same sense, your "HAVE_APPLESPELL" class
>> implements a C++ abstraction layer of Abi's
>> spellchecker class. From a "there's too many
>> abstractions" sense, a willingness to implement this
>> in Abi and not in Enchant would lack both substance
>> and merit.
>>
>> Right now, all we're talking about is writing a simple
>> Enchant backend which talks the AppleSpell protocol.
>> We're not yet proposing to code a plugin *for*
>> AppleSpell based on Enchant. Let's cross that bridge
>> when we come to it. We're not there yet.
>>
>> Besides, since GnomeSpell/Evolution, GtkSpell/Gaim,
>> Kspell, and friends already use Enchant, providing an
>> AppleSpell backend to Enchant would give these apps
>> instant access to AppleSpell, which would in my
>> opinion be ideal.
>>
>>> Anyway, if you thing there's a way to avoid all this
>>> confusion I could
>>> give a shot at the enchant pluggin...
>>
>> I would greatly appreciate that. If not, I'll take
>> your code and craft it to my evil ends.
>>
>> Thanks,
>> Dom
>>
>>
>>
>> __________________________________
>> Do you Yahoo!?
>> Yahoo! Mail - Helps protect you from nasty viruses.
>> http://promotions.yahoo.com/new_mail
>>