To reproduce:

1.  Boink on the location bar
2.  Key in something
3.  Now hit: CONTROL-A (the keybinding for beginning-of-line)
4.  Notice how it doesnt and instead the icon container "selects all"

This is tragic.



------- Additional Comments From tim@eazel.com 2001-02-10 12:20:01 ----

Emacs style locationbar editing conflicts with Nautilus keybindings, such as
Cltr-A, Cltr-F, Cltr-B. (See bug 46375).  Personaly I think temperary disable
Nautilus keybinds for Cltr-A/B/F when locationbar is in editing might be a good
solution. (I like emacs style editing too)



------- Additional Comments From sullivan@eazel.com 2001-02-10 12:27:57 ----

We deliberately disabled the emacs-style keybindings in NautilusEntry to 
allow the menu shortcuts, which are visibly displayed in the user interface, 
to work. It's a choice of supporting the visibly-displayed keyboard 
equivalents or the hidden ones.

I don't know how to make a sensible compromise here. Having a 
preference for this seems bad, but is a way out I suppose. I'm going to 
torture Arlo with thinking about this further by assigning it to him. Made it 
1.0 just to make sure it gets looked at; we don't necessarily need to 
change anything in my opinion.



------- Additional Comments From ramiro@fateware.com 2001-02-11 07:30:32 ----

So I can see the rationale for this.

The only reason why I noticed the bug, is because that is the behavior ive come
to expect with GtkEntry widgets.

So nautilus violating the sanctity of GtkEntry emacs key bindings might make
sense in the grand scheme of things, however its something that will be noticed
as annoying by current GTK+ users.

Oh, yeah, it is also the way Netscape works on Linux.



------- Additional Comments From don@eazel.com 2001-02-15 23:19:03 ----

Not a 1.0 blocker.  Sorry.




------- Additional Comments From sullivan@eazel.com 2001-02-23 17:35:18 ----

I changed the title to reflect the fact that this EMACS-keybinding-ignoring code
is not in the location bar code itself, but in the NautilusEntry class that the
location bar is an instance of. Many of our other text fields in Nautilus are
also of this type, so the same behavior occurs in them.

People used to the Emacs bindings will be very annoyed at this behavior. We've
seen enough evidence of this to know it's true. I think the issue might become
moot in GTK 2.0, because Owen said that they "will probably" change the behavior
to give the global UI pieces like the menu "first crack" at the keyboard
shortcut, and only use it in the focused widget if the menu bar doesn't take it.
This seems to me like the best possible solution. If we get a ton of flack about
this before that solution is implemented, we should probably consider the
preference approach.



------- Additional Comments From darin@bentspoon.com 2001-02-23 17:54:18 ----

One problem related to John's comments above is that some of our GtkEntry-esque 
objects are actual GtkEntry objects, and others are NautilusEntry subclass objects, so 
this is not consistent throughout Nautlius.

I don't know if it's practical to make every single GtkEntry in Nautilus be a NautilusEntr, 
since presumably some are created by library functions.



------- Additional Comments From jacob@ximian.com 2001-03-02 11:42:32 ----

this bug is extremely annoying.

every single other text entry i deal with on a day-to-day basis has C-a, C-e,
and C-k working the same *except* for nautilus.

ESPECIALLY when in some views, the "select all" menu item is DESENSITIZED.

mozilla let's me hit C-a in the location bar and have it work how i'd expect.
when the focus is not there, C-a selects all the text in the page.

PLEASE FIX THIS BEFORE 1.0



------- Additional Comments From sullivan@eazel.com 2001-03-02 11:47:35 ----

I reset the milestone on this just so the triagers could see the 
impassioned plea for fixing this for 1.0.



------- Additional Comments From don@eazel.com 2001-03-02 14:19:37 ----

How hard and/or how risky is the fix?  Do we know how to fix it yet?

And why is this assigned to Arlo?




------- Additional Comments From gzr@eazel.com 2001-03-02 14:28:41 ----

We need an official decision from our usability experts.



------- Additional Comments From don@eazel.com 2001-03-02 14:38:37 ----

Just talked to Arlo and what we really need to do here (until we have globally
configurable key bindings in Nautilus alone or all of GNOME) is make "Use
Emacs-style key bindings in text fields" and advanced user option.

And we can do that in 1.2 so I'm marking this P2 for that milestone.  But we
don't have time for this in 1.0.




------- Additional Comments From sullivan@eazel.com 2001-03-09 14:21:10 ----

See also bug 47625, which is about this same issue (with the sense currently
reversed) in the Notes sidebar panel.



------- Additional Comments From don@eazel.com 2001-03-11 15:59:56 ----

Maciej is working on a possible key bindings change for 1.0.




------- Additional Comments From mjs@noisehavoc.org 2001-03-11 16:17:18 ----

I suggest just taking out the hack to avoid processing Ctrl+A specially in the
location bar for 1.0. It pisses lots of people off and has not made anyone happy
from what I can tell. We can figure out a better solution later.




------- Additional Comments From mjs@noisehavoc.org 2001-03-11 17:11:14 ----

Created an attachment (id=1395)
Patch




------- Additional Comments From mjs@noisehavoc.org 2001-03-11 17:11:47 ----

The patch above just removes the attempt to override local keybindings. A
preference seemed like overkill.




------- Additional Comments From sullivan@eazel.com 2001-03-11 17:52:34 ----

I think there may be confusion as to what we're trying to accomplish here. 
One comment here says that Control-A is a problem in particular. If we 
apply Maciej's patch, Control-A will mean "go to the beginning of the text" 
(i.e., the same thing you would expect Home to do). I would be much 
happier with a universe where Control-A meant "Select All Text". I hope 
somebody doesn't think we're going to get "Select All Text" behavior with 
this patch.

This patch will mean the rebirth of bug 46375 -- so be sure to re-open that 
bug if we take this patch. I think bug 46375 is a serious usability problem 
for non-experts, whereas this bug is a usability problem for emacs-using 
experts. Which audience to we want to please right now? Maybe 
emacs-using experts is the right answer. I just want people to realize that 
this isn't a win-win fix.

I think it's OK to apply this patch, but I want to make it clear that we are 
trading off one problem for another if we do so.



------- Additional Comments From mjs@noisehavoc.org 2001-03-12 06:20:04 ----

Created an attachment (id=1403)
A patch that does it as an expert-only preference




------- Additional Comments From sullivan@eazel.com 2001-03-12 08:46:02 ----

A few comments on the Preferences version of the patch:

(1) The on-screen text is unwieldy and contains a misspelling. It's 
currently

"Let Emacs-style keybindings in location bar take precendece\n"
"over global keyboard shortcuts"

I'd suggest:

"Use Emacs-style keyboard shortcuts in all text fields"

The main thing I don't like about this new wording is that it doesn't tell you 
the trade-off. Maybe:

"Use Emacs-style keyboard shortcuts in all text fields (overriding menu 
shortcuts)"

That probably won't fit on one line anymore. Vera, any better suggestions?

(2) Is "Emacs-style" the right capitalization? (e.g., Emacs, emacs, or 
EMACS?)

(3) The preference affects all NautilusEntry fields, not just the location bar 
text field. We could make it only affect the location bar but I think that would 
be wrong. Note that I took out the "location bar" reference in my proposed 
text. But the name of the preference still has LOCATION_BAR in it, which 
is wrong.



------- Additional Comments From vera@eazel.com 2001-03-12 10:50:27 ----

? Would this fit:

"Use Emacs-style keyboard shortcuts, not menu shortcuts, in text fields."

It does appear that "Emacs" is correct -- capital E, the rest lowercase.



------- Additional Comments From sullivan@eazel.com 2001-03-12 11:05:30 ----

We'd have to try and see if that fits, but it's definitely an improvement over 
any of the earlier proposals.



------- Additional Comments From darin@bentspoon.com 2001-03-12 11:09:57 ----

We use "1 hour" to mean "got the patch, just need to commit", not "0 hours".



------- Additional Comments From sullivan@eazel.com 2001-03-12 13:46:41 ----

Vera's text would still be the longest item anywhere in Preferences, and thus
increase the window width. That's not the case if we leave off the ", not menu
shortcuts," part. I think if we decide to take this at the last minute for 1.0
then we should just use the shorter form:

"Use Emacs-style keyboard shortcuts in text fields" (note lack of period)

After 1.0 we'd like to redesign the layout of the Preferences window somehow so
that we can use a little more explanatory text per item when necessary.



------- Additional Comments From josh@eazel.com 2001-03-12 14:50:25 ----

Ok, from a normal person's point of view, I just learned that most entry fields
use emacs keybindings.  (This is shocking in itself, but that's beside the
point)  

I think that no matter what widget has focus, the program assigned keybindings
should take precedent.  

Either that, or the text in the edit menu should change when you click on an
editable text box (STUPID!)

Josh



------- Additional Comments From vera@eazel.com 2001-03-12 15:25:18 ----

The shortened version is fine.

As another normal person, this took me by surprise, too.



------- Additional Comments From don@eazel.com 2001-03-12 23:17:12 ----

Hmmmm, I would still like this to be some advanced user preference or
something.  Marking this P2 because I wan't us to decide soon.




------- Additional Comments From sullivan@eazel.com 2001-03-13 08:15:56 ----

I think we should check this in as is (with the short form of Vera's text, and 
maybe tweaking the preference name) right away. Maybe we will be able 
to eliminate it some day. Maybe we will improve the text in the future. As is, 
it's definitely something that will make some users very happy.



------- Additional Comments From niles@scyld.com 2001-03-13 14:31:00 ----

*** Bug 47736 has been marked as a duplicate of this bug. ***



------- Additional Comments From niles@scyld.com 2001-03-13 14:47:39 ----

Let me just add my vote that Nautilus is great, but this one issue makes
it totally unusable for me.  I thought Eazel focus was on usability?




------- Additional Comments From jacob@ximian.com 2001-03-15 09:41:03 ----

the attached patch has some bugs.

A-f does word forward instead of bringing up the file menu.  there are two
problems here:

1.  i have a M(eta) key.  i would think M-f should go forward.  Not A-f.
2.  for people without a M key, things suck.

again, we can look at what mozilla does (partly).  M-f types `f' and A-f brings
up the menu.  if we can, M-f should probably jump forward.



------- Additional Comments From sullivan@eazel.com 2001-03-15 09:47:27 ----

Niles: usability means different things to different people.

Jacob: The patch just reverts the behavior to match all other GtkEntry text 
fields. Are you suggesting that we change the behavior to be different from 
other GtkEntry fields?



------- Additional Comments From darin@bentspoon.com 2001-03-15 10:00:24 ----

The problems Jacob mentions are present in all GTK programs that don't go out of
their way to work around them. While we might want to do the same kind of hack
that Mozilla has done to make the alt keys work, I think it's more appropriate
to fix GTK itself.

Jacob, I suggest you write a GTK bug report about those problems.

I'll be applying this patch soon.



------- Additional Comments From darin@bentspoon.com 2001-03-16 14:31:49 ----

Oops. I need to reopen this for consideration for 1.0.2.



------- Additional Comments From sullivan@eazel.com 2001-03-16 14:36:18 ----

Note that Darin started with the patch here, but improved it quite a bit also.



------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:59 -------