Re: Reg. modifying GTK+ to add menu option

[Sindhu S <sindhus live in>]

Hi!

On Thu, Apr 11, 2013 at 6:24 PM, Dieter Verfaillie <dieterv 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?