GNOME Bugzilla – Bug 544092
Ctrl+f should always start a find
Last modified: 2010-05-21 07:22:54 UTC
I often will open many source files from a large project and switch between them using the side pane. My use case is such that I want to click on a document in the side pane and *immediately* search within that document. So I click on document_x, and hit ctrl+f, when I do this gedit believes I want to search the list of documents in the side pane rather than actual document that I thought I just focused. What causes the most frustration is that sometimes I will not notice this behavior immediately and start typing my search term. When I do this the selected item jumps all over the place attempting to locate my search term in the list of document titles. I believe it would make more sense if you press ctrl+f anywhere in the gedit window that the find starts for the currently open document.
I confirm, this problem still exists in gedit 2.28.0. See my bug report and ideas for solutions at: https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/510495
gedit 2.29.8 still suffers from this bug. Some ideas: 1. While the focus is on side pane, *every* key-press opens the search field of the side pane. Therefore I agree with Jon, Ctrl+F could always open the "find in document" dialog or even pass the focus to the document pane. 2. [Esc] should not close side pane. [F9] does this already. Like Nautilus it should only close its search field. 3. A double-click into side pane does the same as a single-click: it changes the current document, but leaves focus on side pane. A double-click could additionally pass the focus to the document pane. Users will get used to this and won't be embarrassed by pressing Ctrl-F while still focusing side-pane. (I'd prefer if all 3 fixes would be applied)
Created attachment 157411 [details] [review] Fixes focusing on the view after clicking on file in File Browser 1. I do not agree it should open the file name matcher. 2. Its just another shortcut that is common to all panels. 3. The documents panel cannot focus on the view because the tree view grabs the focus back, however my patch fixes this for the File Browser.
Created attachment 157461 [details] [review] Updated and fixes focusing for File Browser and Documents Panel
Review of attachment 157461 [details] [review]: Thanks! I tested your patch in a Ubuntu Lucid daily and for me it fixes this bug. Now the focus is always passed to the selected document. I was not able anymore to set the focus to the "Documents" side pane. Pressing keys "abc" to select the first document named "abc*" does not work anymore. But this is ok for me, because the "Documents" side pane is not sorted anyway. Please forget my point 2 in comment #2. I could not reproduce the problem anymore. [Esc] closes the search field if it is open - like Nautilus.
Review of attachment 157461 [details] [review]: I forgot to mark your patch as reviewed. I briefly checked the diff now and saw that you disabled the ability to focus and the search field altogether. As said I think this is a good solution. I see the "Documents" side pane as a kind of vertical tabs.
Review of attachment 157461 [details] [review]: ::: gedit/gedit-commands-file.c @@ +151,3 @@ if (tab != NULL) { + if (loaded_files == 0) why this change? ::: gedit/gedit-documents-panel.c @@ +773,3 @@ gtk_tree_view_set_reorderable (GTK_TREE_VIEW (panel->priv->treeview), TRUE); + gtk_tree_view_set_enable_search (GTK_TREE_VIEW (panel->priv->treeview), FALSE); + gtk_widget_set_can_focus (panel->priv->treeview, FALSE); I do not think I agree with this: I agree that when clicking on a doc the view should get focused, but I think the side pane should stay focusable and searchable. ::: gedit/gedit-tab.c @@ +1989,3 @@ gedit_tab_set_state (tab, GEDIT_TAB_STATE_LOADING); + gtk_widget_grab_focus (GTK_WIDGET (tab->priv->view)); I admit I have not tested the patch, but this feels wrong here... the tab should *already* have focus when the doc is loaded, shouldn't it? Can you explain why is this needed? ::: plugins/filebrowser/gedit-file-browser-view.c @@ +554,2 @@ widget_parent->button_press_event (widget, event); + gtk_widget_set_can_focus (widget, TRUE); This looks very hackish... can you explain why is this needed?
Created attachment 159559 [details] [review] Focus on view when opening files from the File Browser or Documents Panel > why this change? no idea, removed > I do not think I agree with this: I agree that when clicking on a doc the view > should get focused, but I think the side pane should stay focusable and > searchable. search is broken because once a match is found the selection would be moved to it, the tab would be focused causing the view to be focused and closing the search > I admit I have not tested the patch, but this feels wrong here... the tab > should *already* have focus when the doc is loaded, shouldn't it? Can you > explain why is this needed? without it when the first file is opened from the filebrowser it is not focused > This looks very hackish... can you explain why is this needed? needed to prevent the view from refocusing on itself during the chain-up causing the focused tab from being in focus
Created attachment 159919 [details] [review] Focus on view when opening files from the File Browser or Documents Panel (fixes bug #544092) v2
Review of attachment 159919 [details] [review]: See minor comments inline ::: gedit/gedit-commands-file.c @@ +155,3 @@ + gtk_widget_grab_focus (GTK_WIDGET (view)); + + gedit_window_set_active_tab (window, tab); I don't think this is needed, because making a tab active will grab the focus on the view already. ::: plugins/filebrowser/gedit-file-browser-view.c @@ +550,3 @@ if (event->type == GDK_2BUTTON_PRESS) + widget_parent->button_press_event (widget, event); + /* Chain up */ Maybe add a comment here why we chain up before activating the item
Created attachment 159942 [details] [review] Focus on view when opening files from the File Browser or Documents Panel v3
Ok, thanks for all the work! I've committed the patch, with the addition of a grab_focus in set_active_tab (because when the tab is already active, the notebook page is not switched, and the view is not focussed). I also added some comments in the changed places to explain why we disable the search entry, why we disable focus on the treeview, and why we call grab_focus in set_active_tab.
*** Bug 619256 has been marked as a duplicate of this bug. ***