Re: Spell checking in GIO



hi;

On 8 October 2013 18:12, A. Walton <awalton gnome org> wrote:
This argument doesn't convince me much. If we want Search in GNOME Shell to
be spellchecked, you could always just link to enchant for that. Clutter
applications are a bit of an odd case anyways, since Clutter kinda already
wants to be GDK 4.0, which only reinforces my argument that this really
should be in GDK.

no, you *really* don't want to add API to GDK. GDK already has too
much API already. GTK+ is perfectly fine for this job, especially if
it comes with widgets, or with intearction with widgets.

The problem for me is that the only sane way to put this into GIO is to add
an extension point and load in the spell checking module at runtime (which
pretty much everyone agrees in the thread).

whether or not this API should be implemented through extension points
is completely orthogonal: GIO extension points are a public API, and
can be defined and used from GTK as well.

GDK, on the other hand, already links to the necessary dependencies on
Windows and OS X and we'd simply be adding a singular hard dependency on
enchant (or reinventing it ourselves), which most distros aren't going to
complain about (they already package enchant), most users aren't going to
complain about (except the users that hate features; I'm certain we can get
some GNOME Haters in on this), and most developers aren't going to complain
about (since they're probably already using an Egg'd version of
SexySpellEntry or linking their applications to enchant anyways).

I prefer having direct dependencies only for API that expose types in
the GTK API: Cairo, Pango, ATK. if we don't expose any data type from
Enchant (and we probably shouldn't) then I'd prefer to have that
dependency hidden via an extension point — especially because if
Enchant is unmaintained we may want to start using something else in
the future; or we may want to use something else on another platform.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]