Re: GnomeURIEntry

[Ricardo Fernández Pascual <ric users sourceforge net>]

El mié, 25-09-2002 a las 13:13, Bill Haneman escribió:
> 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ó:
> > > - 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)

that link is broken, it is
http://developer.gnome.org/projects/gap/keyboardnav.html

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

What's the alternative proposal? It must be an easy to reach key and if
possible it should not require any modifier, otherwise you miss all the
benefits of it.

I'm sure that every person that has used bash (or any other program that
uses readline or similar) misses tab completion when entering filenames.

This is something that the user should be able to choose from the
keybindings capplet. Maybe a reasonable default is C-tab? 

(Offtopic: I have tried and i can't set C-tab or tab as a keybinding for
anything in the dialog, is that a bug or a feature?)

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

Report specific problems in galeon as bugs. I don't think there is
anything apart of using "tab" for completion. The location entry is just
a GtkCombo + completion + an icon 

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

Me too.

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

Agreed.

A side effect of using galeon entry as the GnomeURIEntry is that galeon
will have a better URL entry wrt accessibility because otherwise I will
not get this good feedback about the requirements. I don't know very
much about this stuff :-(


-- 
Ricardo Fernández Pascual
ric users sourceforge net
Murcia. España.