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 _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
