Re: GnomeURIEntry

[Bill Haneman <bill haneman sun com>]

On Wed, 2002-09-25 at 09:29, Ricardo Fernández Pascual wrote:
> El mar, 24-09-2002 a las 23:44, Matthias Warkus escribió:
> > Hi,
...
> > I think it would be nice if there were a GnomeURIEntry widget that is
> > tailored to have the user enter both local and remote URIs. It would
> > be derived from GnomeFileEntry and offer these additional features:
> 
> Galeon2 has a widget that already does some of these.
> 
> > 
> > - show local files selected via "Browse..." button as file: URIs to
> >   give the user a hint that the entry will accept URIs, not just file
> >   names
> > 
> > - accept URI drops from all relevant sources (Nautilus, major Web
> >   browsers, maybe other GnomeURIEntry widgets)
> 
> Not yet, but planned (and easy to use)
> 
> > - have a URI drag source to the left of the entry maybe? Would be
> >   another hint that the entry accepts URIs

> In galeon, this is a separate widget, but it has already been suggested
> to mix it with the entry. Ideally, we would like to put in inside the
> entry, like mozilla. 
> 
> 
> > - do history autocompletion
> 
> Already does this. Also, I think it should do TAB completion (like bash)
> for local URIs. This is on my TODO list for galeon.

This would conflict with keyboard navigation.  We want to avoid use of
TAB for anything other than "move focus to next widget in focus chain",
or explicit entry of a 'tab' character (see HIG and Keyboard Navigation
spec at http://developer.gnome.org/projects/gap/keynav.html)

Completion is great, but TAB is a very problematic choice.

Also note that any operation such as drag-and-drop, which use the mouse,
need keyboard equivalents.

> Current implementation sorts history matches based in the last time it
> was visited and how often the site is visited.
...

One of the big attractions of a gnome-2 galeon is its potential with
respect to accessibility.  GNOME 2 has a lot of built-in accessibility
support, but in order for it to work, it is vital that applications
don't subvert built-in features such as theming and keyboard navigation,
and that any custom widgets provide appropriate ATK implementations, or
are constructed such that the built-in ATK implementation inherited from
GTK+ works for them.

ATK support for a gtk+-2-based gecko is already underway, and the gtk+-2
port of mozilla already supports the GNOME accessibility APIs ATK and
AT-SPI (via the 'atk bridge').  It would be a great shame and irony if a
GNOME-2 galeon were to lose out on this existing support.

There has been recent discussion about providing assistive technologies
such as 'gok' and 'gnopernicus' as part of upcoming GNOME Desktop
releases, and such has been suggested as soon as GNOME 2.2.  As
accessibility becomes more of a visible part of the GNOME desktop, it
will be increasingly important that new GNOME widgets and application
custom widgets provide suitable accessibility if they are to be bundled
with GNOME or considered fully GNOME-compatible.

So whether we create a GnomeURIEntry or just enhance Galeon's widget, I
do hope we ensure its accessibility.

best regards,

Bill


p.s. - off-the-cuff I would expect a URI widget to export the AtkObject,
and AtkComponent interfaces (for which inherited implementation should
be fine),  AtkEditableText for the text entry and contents, AtkAction
for additional actions like drag-and-drop and 'activate', and if the
widget acts like a combobox then additional actions and the AtkSelection
interface may be appropriate as well.