GNOME Bugzilla – Bug 68174
GtkEntry focus/selection problem
Last modified: 2014-12-06 04:35:53 UTC
When I call gtk_widget_grab_focus on a GtkEntry, all text inside the entry is automatically selected! This is very, very wrong! ;( Sure, I can unselect the text afterwards, but: 1- Why should I have to? 2- Even if I do, the text is still temporarily selected, and whatever primary selection the user might have will be lost. Focus and selection are separate, this looks just a lame attempt to fix broken Input Dialog code. BTW, GtkEntries could use another form of selection, one that doesn't interfere with the pirmary X selection. Its sole purpose would be to let the user replace existing text without having to delete it first. But the primary selection should *never* be automatically selected by a program.
Agree that it might be nice to have a way to grab focus without selecting, but it is correct to select when the user tabs in to the entry. There is no harm to taking the primary selection, if the user wants to preserve data they copy to the clipboard.
I think it's generally right (and windows does it) that if the program grabs focus to an entry when it focuses a dialog, that it comes up selected. There might indeed be cases where this is not desirable, but it's hard for me to imagine what reason an application would typically have for doing this. The reason why there is no "selected but not the selection state" is because it's really confusing - the user should be able to middle-button-paste the selected text always. GTK+-1.2 used two different colors for selected-but-not-the-selection and not-selected, but I don't think most people ever figured that out As Havoc says, users really need to retrain to use the CLIPBOARD (cut/copy/paste) for moving data around -- middle button paste is a nice fast shortcut for experts, but most X users -- even experts, basically believe that there is something broken about the X clipboard mechanism -- because apps try to make the PRIMARY selection into something a bit like the CLIPBOARD.
Just because it is hard to imagine cases where focus->selection would not be wanted, doesn't mean you should enforce this behaviour. As a matter of fact, I've come across one of such 'rare' cases. I have a single/multi-line entry, where users can enter text both in a GtkEntry (single line mode) or GtkTextView (multi line mode). So, I have to give focus to either one of those widgets when the mode is switched, but, when I switch to the GtkEntry, it automatically selects all text, which is very annoying! Besides, Gtk doesn't have to copy everything windows does! And I don't recall windows selecting text in entries when they receive focus. Can't you select text *only* when the GtkEntry is focused explicitly by the user?
Thinking about this some more, it would be a real pain to not select since the ::grab-focus action signal needs to select the contents of the target widget; so, it's almost impossible for the entry to tell whether a call to ->grab_focus() comes from the user or programmer. Considering that I think the right thing to do is virtually always to select, and making gtk_widget_grab_focus() not select would be quite hard to implement, I think it's pretty clear that we should leave it the way it is for now. Maybe in a future version, we can add some gtk_entry_focus_without_selecting() call.
gtk_entry_focus_without_selecting() sounds fine to me. In the mean time, I can always blame gtk when users complain about losing their selection. O:-)
Doesn't Ctrl-Z or Escape replace the selected text, or is that up to the application programmer? That's what Mozilla does, at least.
Version 2.0 of the HIG[1] fully supports my arguments. Pay special attention to what is in parenthesis: «When the user gives focus to an entry field using the keyboard, place the text cursor at the end of the existing text and highlight its contents (but don't overwrite the existing PRIMARY clipboard selection). This makes it easy to immediately overtype or append new text, the two most common operations performed on entry fields.» [1] http://developer.gnome.org/projects/gup/hig/hig-diff/controls-entry.html
*** Bug 304178 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > As Havoc says, users really need to retrain to use the CLIPBOARD > (cut/copy/paste) for moving data around -- middle button paste > is a nice fast shortcut for experts, but most X users -- even > experts, basically believe that there is something broken > about the X clipboard mechanism -- because apps try to make > the PRIMARY selection into something a bit like the CLIPBOARD. The first application for the X Window System was the X terminal. It told the users to use the mouse to paste, and they did. Most X users did, and I believe that they still do because it is the most convenient way to move data around. Using the clipboard rather difficult and unobvious when the data live in a terminal window, as in the following scenario: 1. Mark the error line number in the terminal window. 2. Tell Geany to go to the offending line. * Geany shows the line dialog box with the current line selected. * When you delete the current line and paste from PRIMARY, the current line returns! The workaround is to use the X Clipboard manager, but it is both annoying and distracting when you have to do this many times.