Re: gtkspell (was Re: Announcing: Project Ridley)

[Mike Hearn <mike plan99 net>]

Dominic Lachowicz wrote:
> > > I'm not a Gtk+ developer, but I think one of the criteria for being
> > > considered is: doesn't introduce a new library dependency, or maybe it
> > > can, if it really makes sense. Gtk+ depending on a spell checking
> > > library hardly makes sense, however.

I have to ask - why not? A spelling checker is a part of the Cocoa 
framework on MacOS X and nobody seems to think this is strange or 
unusual. I'd say any modern widget toolkit should depend on such a thing.

> Enchant has been API/ABI stable for a while now, so I wouldn't mind
> proposing it for inclusion to the platform at some future point (or
> better still, free desktop).
>
> Chris Hammond's libsexy has a spell checking enabled GtkEntry subclass
> that depends on Enchant. It dlopen()'s the .so and looks up the
> functions by name rather than linking against it explicitly. If the
> module isn't found, spell checking is disabled. This might be
> something of a compromise solution, since it gives consumers a soft
> dependency on a spell checking lib rather than a hard dependency.

One thing to bear in mind - which we can't do all that much about except 
curse our UNIX ancestors right now - is that implicitly loading a 
spelling checker library will on most Linux systems break some C++ 
applications (heap corruption etc) due to the usual ELF symbol scoping mess.

But I don't think this is an argument for not having it in GTK+, rather 
it's just some encouragement to the C++ toolchain people to get their 
act together and worth remembering if you guys go ahead with this. At 
least, there should be some way to programmatically/environmentally 
ensure the spelling checker infrastructure is never loaded to ease the 
pain a bit.

thanks -mike