octave-bug-tracker
[Top][All Lists]
Advanced

[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: Sun, 15 Apr 2018 14:19:20 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

URL:
  <http://savannah.gnu.org/bugs/?53663>

                 Summary: File Editor search / find dialog box doesn't
function well, needs restructure 
                 Project: GNU Octave
            Submitted by: sebald
            Submitted on: Sun 15 Apr 2018 06:19:18 PM UTC
                Category: GUI
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Other
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: dev
        Operating System: Any

    _______________________________________________________

Details:

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.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?53663>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

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