Re: GnomeURIEntry

[Bill Haneman <bill haneman sun com>]

On Wed, 2002-09-25 at 12:59, Ricardo Fernández Pascual wrote:

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

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

The trouble with a "no modifiers" key in a text entry is that it's
likely to conflict with text characters themselves.  Spacebar might be
attractive (since it's not a viable character in URIs), but that would
conflict with the use of spacebar for "activate" which is fairly
consistent on the desktop.

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

But users who needed keyboard navigation would miss being able to
navigate the UI ;-)
 
> This is something that the user should be able to choose from the
> keybindings capplet. Maybe a reasonable default is C-tab? 

C-tab would conflict with the use of Control-tab to "get out" of
multi-line textfields, which necessarily must not use TAB for
navigation.  But this is an exception for multi-line text fields only,
extending it to other kinds of text fields would seriously impact the
usability of keyboard navigation.  Alt-tab us used for the default
window manager bindings.

Basically, use of TAB in any combination for completion will conflict
with the use of TAB elsewhere.  That wasn't a problem for bash of
course, since bash predates the use of GUIs, etc.

"Enter" is probably confusing also.  CSH uses "Esc" but that also seems
at odds with other uses of Esc on the GNOME desktop.  

Calum, what do you suggest?

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

OK, I don't know if anyone has had a chance to test the accessibility of
the galeon-2 port yet (at least, the UI part and not the gecko content
pane, which is so new that the gecko ATK work probably has not been
integrated in to the galeon UI's ATK hierarchy yet).
...

> > 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 :-(

I will try to give as many suggestions as you need, sorry that I am very
busy these days (like you too, I am sure :-)

best regards,

-Bill
 
> 
> -- 
> Ricardo Fernández Pascual
> ric users sourceforge net
> Murcia. España.
> 
> _______________________________________________
> gnome-hackers mailing list
> gnome-hackers gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-hackers
> 


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers