[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #53663] File Editor search / find dialog box d

From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #53663] File Editor search / find dialog box doesn't function well, needs restructure
Date: Mon, 23 Apr 2018 00:52:41 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

Follow-up Comment #2, bug #53663 (project octave):

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.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]