After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 335169 - Find dialog should start with last search pre-selected
Find dialog should start with last search pre-selected
Status: RESOLVED FIXED
Product: gedit
Classification: Applications
Component: general
2.14.x
Other Linux
: Normal minor
: ---
Assigned To: Gedit maintainers
Gedit maintainers
Depends on:
Blocks:
 
 
Reported: 2006-03-19 22:47 UTC by Sebastien Bacher
Modified: 2006-03-23 22:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Select the search entry contents when focused (1.85 KB, patch)
2006-03-19 23:32 UTC, Steve Frécinaux
none Details | Review
Fix search selection focus (877 bytes, patch)
2006-03-23 18:22 UTC, jessevdk@gmail.com
committed Details | Review

Description Sebastien Bacher 2006-03-19 22:47:08 UTC
That bug has been opened on https://launchpad.net/distros/ubuntu/+source/gedit/+bug/34869

"When you press CTRL-F to find something in gedit, the last search terms should be pre-selected so that you can start typing a new search over the old one.

Currently, to make a new search, you have to press CTRL-F, then delete the old terms, and type the new ones."
Comment 1 Steve Frécinaux 2006-03-19 23:32:14 UTC
Created attachment 61580 [details] [review]
Select the search entry contents when focused

It basically does what the bug describes but it has also the drawback that it selects the entry contents everytime it is focused (before the cursor was put at the end of the entry)
Comment 2 Christian Persch 2006-03-20 12:44:34 UTC
Wouldn't it be easier to just gtk_widget_grab_focus (entry) when showing the dialogue with Ctrl-F ?
Comment 3 jessevdk@gmail.com 2006-03-23 18:22:00 UTC
Created attachment 61859 [details] [review]
Fix search selection focus

This is actually a much simpler approach. It makes sure to first chain up the focus_in event so the window puts the focus on its default focus widget being the entry. Then on first showing the GTK_WIDGET_HAS_FOCUS will return true for the entry and the set_position won't be called. I think this is the correct behaviour.
Comment 4 Paolo Borelli 2006-03-23 19:04:30 UTC
I tested out the Jesse's patch. It seems to be working correctly in all the cases I could think of and restores the behavior of 2.12.

I think we should get this in both on HEAD and on the 2.14 branch.
Comment 5 Paolo Maggi 2006-03-23 19:53:12 UTC
Why do we call "set_position"? I don't remember why we decided to do so.

Comment 6 Paolo Borelli 2006-03-23 19:58:16 UTC
ctrl+f, search, focus the document, then reclick on the entry with the mouse: in this case the text should not be selected, which is instead the default GtkEntry behavior on focus
Comment 7 Paolo Maggi 2006-03-23 20:20:26 UTC
Ok. I remember now
Please, commit with a comment on why we use set_position and why we chain up the focus_in event (on both HEAD and gnome-2-14)
Comment 8 Paolo Borelli 2006-03-23 21:57:27 UTC
maybe it's just me being stubborn, but I can't convince myself of that code...

I tried removing the whole the whole focus-in-event overriding from the search dialog and things seems to behave as expected. Can anyone of you guys find a case where removing the whole focus in handler behaves differently from the above patch?

If only I could remember why we added that code in the first place... :(
Comment 9 Paolo Borelli 2006-03-23 22:00:29 UTC
Jesse, I now recall that we added after a report from you

http://cvs.gnome.org/viewcvs/gedit/gedit/dialogs/gedit-search-dialog.c?r1=1.4&r2=1.5

do you remember the use case?
Comment 10 Paolo Borelli 2006-03-23 22:03:41 UTC
right, it was:

- popup the dialog
- search a word by clicking on find
- focus the document
- hit ctrl+F

-> without the callback the focus is on the button, we want it on the entry
Comment 11 Paolo Borelli 2006-03-23 22:26:41 UTC
Ok, sorry for the noise. I verified that the patch deals with the above use case.

I added the comment as requested by Paolo anc committed.