[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:
<http://savannah.gnu.org/bugs/?53663>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/