Hi!
On Thu, Apr 11, 2013 at 6:24 PM, Dieter Verfaillie <
diet...@optionexplicit.be> wrote:
> As an example, attached is a standalone (very incomplete and not very
> well tested) Python script using Atspi, Wnck and Gdk via
> gobject-introspection
> (originally based on code from Accerciser) that retrieves the word
> under the mouse pointer (if any) using AT-SPI.
Using the accessibility framework to power the look-up functionality is an
amazing and elegant solution. I ran the code and verified it works well,
but I do have the following concerns:
1. It bases the word discovery on the current location of the mouse. This
might be slightly awkward for keyboard heavy users, who would prefer
pressing a keystroke. That said, knowing the exact position of the word on
the screen (in a cross-application way) makes it much easier to draw a good
Lookup bubble.
2. It doesn't solve the problem of lack of discoverability of the option.
Having it in the context menu might help beginners who might not even be
aware of a built-in dictionary in GNOME.
Still, using the accessibility framework seems to be best way to solve the
"find current word" problem. So here's my proposal to solve the
"discoverability" problem:
Similar to `nautilus-scripts`, GTK can look for scripts in
"~/.gnome3/text-scripts" and insert a context menu for each of them (and
pass info on the current textview to the script)
This way, people can add "Search on Internet", "Find on Wikipedia", etc and
people maybe even extend it in interesting ways ("create pastebin paste",
"send to mobile device")
This solves both problems, while keeping the Lookup functionality outside
GTK+ Core.
Would something like this be a more appropriate solution?
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
