bugGNU Octave - Bugs: bug #53663, File Editor search / find dialog...

 
 

bug #53663: File Editor search / find dialog box doesn't function well, needs restructure

Submitter:  Dan Sebald <sebald>
Submitted:  Sun 15 Apr 2018 06:19:18 PM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 15 Feb 2020 10:02:54 PM UTC, comment #7: 
Torsten Lilge <ttl>
Group Member
Fri 01 Jun 2018 07:36:32 AM UTC, comment #6: 

"I think a Qt Widget has some kind of focusInEvent() signal."

Or maybe it is a virtual function that can be over-ridden; I can't recall.

Dan Sebald <sebald>
Fri 01 Jun 2018 07:34:12 AM UTC, comment #5: 

Yes, I think the single find dialog box would be better.  I'm not sure exactly how it should function; I think you're judgment would be better than mine, so please do make the change if you want to.  To me, it makes more sense that the dialog box simply contain the most recent search regardless of what editor window it is in.  I think when people search for something in one file and can't find it, they might search for the same thing in another file.

I typically keep code hunks I was working on (then took a break) in a *.diff file, but I can't find such a thing for this one.  The change should be pretty straightforward though.  I think a Qt Widget has some kind of focusInEvent() signal.  When that happens for an editor tab, just have that tab disconnect the search object signal/slots and re-establish signal/slots with the tab using "this".

Dan Sebald <sebald>
Fri 01 Jun 2018 05:56:15 AM UTC, comment #4: 

Dan, I think we really should go for one find dialog box for all editor files. In comment #2, you mentioned that you have already started to implement this, is this correct? If not, would I would do this the next days.

Torsten Lilge <ttl>
Group Member
Tue 01 May 2018 07:03:20 AM UTC, comment #3: 

I agree that one dialog for all editor tabs would be more useful. I am still wondering why the shortcut behavior differs depending on the systems.

Torsten Lilge <ttl>
Group Member
Mon 23 Apr 2018 04:52:41 AM UTC, comment #2: 

On my system, searching isn't quite as complete.  If the search/replace window does not have focus (for example I click in the editor window and place the cursor in some text) Ctrl+G does not work.  This is true in both docked Editor and floated Editor.

I started down the path of having just a single search/replace dialog about a week ago, then paused because of some comments in the code about having multiple find dialogs:


    // The find_dialog feature doesn't need a slot for return info.
    // Rather than Qt::DeleteOnClose, let the find feature hang about
    // in case it contains useful information like previous searches
    // and so on.  Perhaps one find dialog for the whole editor is
    // better, but individual find dialogs has the nice feature of
    // retaining position per file editor tabs, which can be undocked.


Who knows, I might have written that thinking multiple dialogs was advantageous at the time.  In practice, though, it might be a different story.  However, I do suspect that floating/docking an editor window will complicate the presence of a find-dialog.  Because the widget makes such a drastic change, maybe there is a chance that the signals and slots connections could be lost and re-establishing those connections is necessary in the make_window() and make_widget() routines.

In any case, it should be easy to implement the single search/replace dialog.  Whenever the editor gains focus, disconnect the connections to the find/replace dialog and establish new connections to the currently focused editor tab window.

Before doing that, I wanted to make sure there was an understanding of what the behavior should be.  I guess my preference is a single search/replace dialog box that remains in its one position, unless the user repositions the dialog.  And, I suppose I also would prefer that the contents of the search combo box, i.e., the "search-for-text" remains the same between one editor tab and another rather than replacing with the latest search string of whatever tab-window becomes focused.  My thinking is that if some user is searching for a particular string in one file, s/he might also want to search for that same string in another file.

Dan Sebald <sebald>
Sun 22 Apr 2018 12:50:07 PM UTC, comment #1: 

I have tested this on Ubuntu with Unity and KDE and on both systems the shortcuts are working as expected, i.e.:

  • Ctrl-F opens the search dialog
  • Ctrl-G (or whatever is configured for this action) repeats the search even if the search dialog does not has focus or is closed. This does depend on the floating state of the editor.
Torsten Lilge <ttl>
Group Member
Sun 15 Apr 2018 06:19:18 PM UTC, original submission:  

In reviewing the following bug

https://savannah.gnu.org/bugs/?53657

I noticed the undesirable behavior of the Editor Ctrl+F search/find dialog box.  Here's the summary:

In my testing here with the latest stable version I'm seeing some annoying bugs concerning the Editor's Ctrl+F find behavior. Ctrl+F, Ctrl+G, Ctrl+Shift+G and Escape all work, but the context in which they are active is dependent on which window has focus. The way I currently see this is practically an unusable search.

When Editor is docked and focused, Ctrl+F opens a dialog search window. Ctrl+G, Ctrl+Shift+G and Escape all work when the dialog window has focus. But if clicking in the Editor to focus, these three no long work. It would be nice if they did because then those shortcuts would still work even though the dialog box is closed. (See the Documentation window behavior, and note that FireFox browser does the same thing...Ctrl+G still works after closing its "find footer".)

When Editor is floating, Ctrl+F also opens a dialog search window, but the situation is worse in the sense that the floated Editor window moves behind the main Octave GUI window. Trying to get the Editor window and search dialog box visible at the same time doesn't work.

It appears to me that the Editor's Ctrl+F search dialog box has the wrong parent (the main GUI window) when it should be the Editor window as parent...  This is in fact the case, having looked at some code.  In file-editor-tab.cc


    if (! _find_dialog)
      {
        _find_dialog = new find_dialog (_edit_area,
                                        fetab_actions.mid (0,2),
                                        qobject_cast<QWidget *> (sender ()));
[snip]
      }


That _find_dialog is a non-static member variable.  That suggests that each file-editor-tab widget gets its own search dialog box.  That is what happens.  I've opened two files in the Editor, typed cntr+F in both windows and the dialog box hides/shows with each press of a tab to change focus.  I don't think it is desirable to have the appearance of search dialog changing position, especially when the widgets are in a tabbed stack all occupying the same geometry.

I mentioned the search dialog seeming to behave as though it is parented by the GUI, i.e., the application level, rather than the Editor window.  Something strange might happen during the process of floating the Editor widget into a window.  Perhaps the Window Manager has to make a decision as what to do with tha (possibly hidden) dialog box because that dialog box is a stand-alone window.  Maybe it becomes orphaned in a sense so Qt ties its behavior to the app rather than the original Editor window.

So, I'd propose that there should be just one search/find dialog box created for the Editor octave_dock_widget, not for any particular file_editor_tab.  That way, the search dialog and Ctrl+G, Ctrl+Shift+G and Escape should work for all the file_editor_tabs.  (If it is desired to have the contents of the search dialog change with the active editor tab, save the previous search text and put it into the search dialog when the file_editor_tab becomes focused again.)  Also, special care is going to be needed to make sure to retain the parent for the search/find dialog when it goes through the make_window() and make_widget() transition routines.

Not difficult stuff, but far too much for 4.4.0 release.  Plus, there are some unfinished changesets concerning a robust make_window/make_widget transition which should be debugged and tested first.

Dan Sebald <sebald>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by sebald (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-02-15 ttl StatusNone Fixed
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code