Re: Spell checking in GIO

[Andrew Cowie]

On Tue, 2013-10-08 at 09:49 -0400, Matthew Barnes wrote:

> Or perhaps follow the "glib-networking" pattern where GIO just defines a
> spell checking interface and an extension point and the meaty parts with
> the extra dependencies are supplied by 3rd party module(s).

Speaking of which, do we really need to have so many different
back-ends? We made a hard decision about the input method framework
requirement, maybe we should just pick a dictionary provider and go with
it?

AfC
Sydney


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Spell checking in GIO

[Коростіль Данило]

shouldn't a spelling checker be optional feature in a GUI toolkit?  It 
adds bloat to applications that have no text entry scenarios (say one 
which uses GUI for menu only), to say the least


Sure. It must be option in GTK widget to enable/disable spell check 
support I guess. Apparently app developer should choose it. That why GTK 
is good for that job.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Spell checking in GIO

[Andy Tai]

shouldn't a spelling checker be optional feature in a GUI toolkit?  It adds
bloat to applications that have no text entry scenarios (say one which uses
GUI for menu only), to say the least


On Tue, Oct 8, 2013 at 11:46 AM, Коростіль Данило
wrote:

> It seems to have spell checking in GTK is fine to most folks.
>
> As i18n member I want to see the spell check engine tied to input source
> method. That means to change spell check dictionary to relevant input
> source method. In other words, I want to correct text I'm typing regarding
> to current keyboard layout.
>
> Jasper pointed me that can be done by GtkIMContext. So it makes sense to
> build it in GTK.
>
> __**_
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/**mailman/listinfo/gtk-devel-**list
>



-- 
Andy Tai, a...@atai.org, Skype: licheng.tai
Year 2013 民國102年
自動的精神力是信仰與覺悟
自動的行為力是勞動與技能
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Spell checking in GIO

[Коростіль Данило]

It seems to have spell checking in GTK is fine to most folks.

As i18n member I want to see the spell check engine tied to input source 
method. That means to change spell check dictionary to relevant input 
source method. In other words, I want to correct text I'm typing 
regarding to current keyboard layout.


Jasper pointed me that can be done by GtkIMContext. So it makes sense to 
build it in GTK.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Spell checking in GIO

[Matthew Barnes]

On Tue, 2013-10-08 at 12:29 -0400, Ryan Lortie wrote:
> The other option would be just to have it in Gtk.  I'm not totally
> convinced yet that this belongs in GIO (although, seriously... someone
> added _menus_ to GIO, so why not?).

I'd prefer it remain in GIO simply because looking up spelling
suggestions doesn't really require graphics capabilities, and having it
in GTK+ could preclude some non-graphical tool or library from using it
in the future.

That said, my use case is Evolution so I could cope it with either way.

Matthew Barnes

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Spell checking in GIO

[Emmanuele Bassi]

hi;

On 8 October 2013 18:12, A. Walton  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/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Spell checking in GIO

[A. Walton]

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.

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). The problem with that approach
is that one of the reasons cited many moons ago for not having a
GPlatform/GDesktop/GLivesBetweenGlibandGtk library is so that we don't have
to load a ton of libraries on start.

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).

It's going to be hard to convince me that this shouldn't live in GDK/GTK+.
But I probably don't wear enough merit badges these days to count for much.

(sorry for the resend Christian).


On Mon, Oct 7, 2013 at 9:54 PM, Christian Hergert wrote:

> On 10/07/2013 09:36 PM, A. Walton wrote:
>
>> My only question is why GIO and not GDK? This kind of per-platform API
>> would happily reside in GDK and prevent us from adding even more extension
>> points to GIO. There's really nothing I/Oish about this API (despite GIO
>> already being the home for lost GObjects since there's no GDesktop library
>> between Glib and GTK+), and I can't think of any obvious applications that
>> would want spell checking and not want GTK+.
>>
>> Is there a good reason for spell checking to be this low in the stack?
>>
>
> There are certainly cases such as Clutter applications that need not rely
> on Gdk.
>
> Additionally, it could be used for something like Search in GNOME Shell.
> First run the search text through spell check and search the corpus against
> all possible suggestions to catch things like "friefox".
>
> -- Christian
>
>
> __**_
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/**mailman/listinfo/gtk-devel-**list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Spell checking in GIO

[Emmanuele Bassi]

hi;

On 8 October 2013 05:54, Christian Hergert  wrote:
> On 10/07/2013 09:36 PM, A. Walton wrote:
>>
>> My only question is why GIO and not GDK? This kind of per-platform API
>> would happily reside in GDK and prevent us from adding even more extension
>> points to GIO. There's really nothing I/Oish about this API (despite GIO
>> already being the home for lost GObjects since there's no GDesktop library
>> between Glib and GTK+), and I can't think of any obvious applications that
>> would want spell checking and not want GTK+.
>>
>> Is there a good reason for spell checking to be this low in the stack?
>
>
> There are certainly cases such as Clutter applications that need not rely on
> Gdk.

and by "Clutter applications" I think you mean GNOME Shell, though
it's not strictly necessary: GNOME Shell already can use GDK and GTK
API, if not widgets.

honestly, I'd see this to be part of GTK only. if we want to do the
usual "basic, generic data structures in GIO; presentation layer in
GTK" split, it'd be equally fine by me.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Spell checking in GIO

[Ryan Lortie]

hi,

On Tue, Oct 8, 2013, at 9:49, Matthew Barnes wrote:
> Or perhaps follow the "glib-networking" pattern where GIO just defines a
> spell checking interface and an extension point and the meaty parts with
> the extra dependencies are supplied by 3rd party module(s).

+1 from me.  This is the only way that we could reasonably do it, in my
opinion.


The other option would be just to have it in Gtk.  I'm not totally
convinced yet that this belongs in GIO (although, seriously... someone
added _menus_ to GIO, so why not?).


Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Spell checking in GIO

[Dan Winship]

On 10/08/2013 11:25 AM, Jasper St. Pierre wrote:
> glib-networking exists for political reasons. I don't think we want to
> repeat that with something we can just import in-tree.

No, glib-networking exists for the same reasons as gvfs; to avoid having
circular dependencies (libproxy depends on glib), and to avoid adding
lots of extra dependencies (eg, gnutls) to glib.

-- Dan

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: API break in GtkAction?

[Matthias Clasen]

On Tue, Oct 8, 2013 at 9:45 AM, Sébastien Wilmet  wrote:

> On Mon, Oct 07, 2013 at 06:39:41PM -0400, Matthias Clasen wrote:
> > I've just pushed a testcase (
> > https://git.gnome.org/browse/gtk+/tree/tests/teststockbuttonmenu.c) that
> > shows things related to stock icons, buttons, menuitems and actions
> working
> > as I would expect them to, including gtk_action_set_always_show_image.
>
> Thanks. With a little more investigation, what worked with GTK+ 3.8 and
> doesn't work anymore is to call gtk_action_set_always_show_image() after
> the widgets are added to their containers.
>
>
Ah, ok. We should probably figure out what changed to break that.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Spell checking in GIO

[Jasper St. Pierre]

glib-networking exists for political reasons. I don't think we want to
repeat that with something we can just import in-tree.


On Tue, Oct 8, 2013 at 9:49 AM, Matthew Barnes  wrote:

> On Tue, 2013-10-08 at 08:58 -0400, Dan Winship wrote:
> > enchant depends on glib, so yes, a hard dependency on it from glib would
> > be a problem. But enchant development has more or less stopped (last
> > commit was two years ago), and if glib had equivalent functionality then
> > enchant would be pretty much unnecessary. So it might make more sense to
> > just absorb it into glib (which Dom seemed in favor of in that bug
> anyway).
>
> Or perhaps follow the "glib-networking" pattern where GIO just defines a
> spell checking interface and an extension point and the meaty parts with
> the extra dependencies are supplied by 3rd party module(s).
>
> "glib-spell-checking" anyone?  :)
>
> Matthew Barnes
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>



-- 
  Jasper
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Spell checking in GIO

[Matthew Barnes]

On Tue, 2013-10-08 at 08:58 -0400, Dan Winship wrote:
> enchant depends on glib, so yes, a hard dependency on it from glib would
> be a problem. But enchant development has more or less stopped (last
> commit was two years ago), and if glib had equivalent functionality then
> enchant would be pretty much unnecessary. So it might make more sense to
> just absorb it into glib (which Dom seemed in favor of in that bug anyway).

Or perhaps follow the "glib-networking" pattern where GIO just defines a
spell checking interface and an extension point and the meaty parts with
the extra dependencies are supplied by 3rd party module(s).

"glib-spell-checking" anyone?  :)

Matthew Barnes

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: API break in GtkAction?

[Sébastien Wilmet]

On Mon, Oct 07, 2013 at 06:39:41PM -0400, Matthias Clasen wrote:
> I've just pushed a testcase (
> https://git.gnome.org/browse/gtk+/tree/tests/teststockbuttonmenu.c) that
> shows things related to stock icons, buttons, menuitems and actions working
> as I would expect them to, including gtk_action_set_always_show_image.

Thanks. With a little more investigation, what worked with GTK+ 3.8 and 
doesn't work anymore is to call gtk_action_set_always_show_image() after 
the widgets are added to their containers.

Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Spell checking in GIO

[Dan Winship]

On 10/08/2013 12:36 AM, A. Walton wrote:
> My only question is why GIO and not GDK? This kind of per-platform API
> would happily reside in GDK and prevent us from adding even more
> extension points to GIO. There's really nothing I/Oish about this API
> (despite GIO already being the home for lost GObjects since there's no
> GDesktop library between Glib and GTK+)

It's been suggested that GIO "really" stands for "GLib's Interesting
Objects" or something like that. Anyway, there is no expectation at this
point that things added to it are especially I/O-related. libglib is for
generically-useful stuff that doesn't depend on GObject, libgobject is
basically reserved for the object system itself and stuff very closely
tied to it (eg, GBinding), and libgio is for generically-useful stuff
that does depend on GObject.

On 10/07/2013 04:38 PM, Sébastien Wilmet wrote:
> How to handle the dependency to enchant in GIO? Is a hard dependency a 
> problem?

enchant depends on glib, so yes, a hard dependency on it from glib would
be a problem. But enchant development has more or less stopped (last
commit was two years ago), and if glib had equivalent functionality then
enchant would be pretty much unnecessary. So it might make more sense to
just absorb it into glib (which Dom seemed in favor of in that bug anyway).

-- Dan

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

More simple patch review requests to resolve old bugs

[Timothy Arceri]

Hi Guys,

Thanks for the positive response to my last few patches. Here is two more very 
simple ones for review.

1. Three line patch removing call to g_file_test(). According to the 
g_file_test() documentation g_file_test() should not be used this way so I 
think this change is the correct thing to do. 

https://bugzilla.gnome.org/show_bug.cgi?id=168530

2. This patch just marks a bunch of strings as translatable its just an updated 
version of an old patch.

https://bugzilla.gnome.org/show_bug.cgi?id=452949

Thanks,
Tim

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list