bugGNU Octave - Bugs: bug #57238, Find popup window for GUI editor...

 
 

bug #57238: Find popup window for GUI editor needs more practical positioning

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Thu 14 Nov 2019 09:57:01 PM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  ttl
Originator Name:  Philip Nienhuis 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

Sun 15 Dec 2019 09:46:56 AM UTC, comment #14: 

Changeset http://hg.savannah.gnu.org/hgweb/octave/rev/6bbff502f89d implements the mru lists for search and replace texts. I suggest to close the bug report and possibly open a new one if a  non-floating find & replace is desired.

Torsten Lilge <ttl>
Group Member
Wed 11 Dec 2019 05:52:32 AM UTC, comment #13: 

Good question. I tend to leave this report open until the mru-lists for search and replace terms are done.

Torsten Lilge <ttl>
Group Member
Tue 10 Dec 2019 09:35:12 PM UTC, comment #12: 

Yep, works again, thank you very much.

What shall we do,

  • keep open & change title to reflect remaining wishes in comment #7 ?
  • or close as the original issue has been solved ? (and maybe open a new bug report if those remaining wishes pop up again later ?)
Philip Nienhuis <philipnienhuis>
Group Member
Mon 09 Dec 2019 09:49:59 PM UTC, comment #11: 

Changeset http://hg.savannah.gnu.org/hgweb/octave/rev/eb64fd6209c2 should fix the button issues.

Torsten Lilge <ttl>
Group Member
Mon 09 Dec 2019 08:56:48 PM UTC, comment #10: 

Oops, I have only tested by using the shortcuts. I can confirm the issues with the "find next" and "find previous" buttons. Guessing that just some signal connections are missing, this should be fixed soon.

Actually, selecting "backwards" and using "find next" is the same as "find previous", but in this case "replace" also searches backward for the next search hit.

Torsten Lilge <ttl>
Group Member
Mon 09 Dec 2019 08:35:44 PM UTC, comment #9: 

On Linux (Mageia 7) the Find next and Find previous buttons don't work either.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 09 Dec 2019 12:05:54 PM UTC, comment #8: 

Thanks Torsten.
The dialog is in a better position now (lower right of the editor pane).
The find dialog position is also retained now in qt-settings or octave-gui.ini, nice.

However, there is now a new problem: at least on Windows, the Find dialog doesn't work anymore. Entering a search term and clicking "Find next" of "Find previous" does nothing.

BTW I also found that under "More..." there's an option "Search backward" that doubles with "Find previous".

(Status -> In progress)

Philip Nienhuis <philipnienhuis>
Group Member
Sun 08 Dec 2019 08:48:47 PM UTC, comment #7: 

Changeset http://hg.savannah.gnu.org/hgweb/octave/rev/5169ed0ff0f0 implements only one find dialog with hopefully more useful initial position and restoring position from the previous session. By restructuring the related code it was not helpful to really separate steps 1 and 2. I hope to have tackled down most issues when editor is undocke/redocked or just changes focus.

Still missing:

  • mru lists for search and replace terms
  • different search and replace terms for each editor tab
Torsten Lilge <ttl>
Group Member
Sat 16 Nov 2019 06:34:53 PM UTC, comment #6: 

Yeah, but "one find dialog" for several tabs can be limited. But e.g., notepad++ behaves the same.

A history list (of limited length, say 10-15 items or so, oldest shifts out when a new one comes in) would be great, both for find and replace items.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 16 Nov 2019 03:56:48 PM UTC, comment #5: 

1a, 1b, 2a agreed.

2b really seems to be a contradiction to me. whoat about a history list of search and replace terms instead?



Torsten Lilge <ttl>
Group Member
Sat 16 Nov 2019 03:09:16 PM UTC, comment #4: 

A little more fine-grained:

1a Fix popup location
1b Retain previous dialog popup location (that is the other grudge I have, each new dialog always opens in the far lower left of the screen), perhaps also between sessions

2a Use only one dialog for all tabs
2b Use one file dialog but with possibly different search terms for each tab (or is that contradictory?)

Philip Nienhuis <philipnienhuis>
Group Member
Sat 16 Nov 2019 02:25:06 PM UTC, comment #3: 


> A find toolbar could be configurable. Much SW that I'm using has such a toolbar, or a "sub-toolbar"/toolbar-pane, that pops up when typing Ctrl-F and can be closed with a close button.
> But I have no idea how much work it'll be to add it.


This wouldn't be too hard to implement as we are already using a find bar in the documentation viewer, but without options to select.
 

> If only the current find popup window could be placed in a more practical position, possibly relative to the editor pane in any position (docked or undocked) I'd be very happy already.
> I wonder how it would work out with a docked editor in tabbed position. Just guessing the find popup should disappear if the editor tab isn't in the foreground.


I suggest the three steps

  1. Fix popup location
  2. Use only on dialog for all tabs
  3. Use a toolbar in stead a separate dialog window (which should probably discussed in the maintainers list before)


where steps 2 and 3 have a lower priority.

Torsten Lilge <ttl>
Group Member
Sat 16 Nov 2019 12:21:31 PM UTC, comment #2: 

Thanks for your comments.

A find toolbar could be configurable. Much SW that I'm using has such a toolbar, or a "sub-toolbar"/toolbar-pane, that pops up when typing Ctrl-F and can be closed with a close button.
But I have no idea how much work it'll be to add it.

If only the current find popup window could be placed in a more practical position, possibly relative to the editor pane in any position (docked or undocked) I'd be very happy already.
I wonder how it would work out with a docked editor in tabbed position. Just guessing the find popup should disappear if the editor tab isn't in the foreground.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 15 Nov 2019 06:02:16 AM UTC, comment #1: 

Thanks for the report, Philip. The positioning of the find dialog is definitely not very intuitive. I remember that its behavior changed some time ago (not intentionally) but I did not have the time to tackle it down.

I agree that one dialog for all tabs is probably the expected behavior from other editors.

However, I am more reluctant regarding a find toolbar which would consume valuable vertical space and where it is hard to present many search options in a clear and well organized way.

Torsten Lilge <ttl>
Group Member
Thu 14 Nov 2019 09:57:01 PM UTC, original submission:  

On my dual screen desktop I usually have the undocked editor on the right screen, and Octave's main window in the lower half on the left screen.
When I hit Ctrl-F to get a find popup it usually opens in the lower left corner of my left screen, i.e., as far as possible from the editor where I need it. This is very clumsy IMO.

I'd suggest to position this find popup in the upper left corner of the editor pane, more or less like attached pic.
I can imagine that for a docked editor this position could also be more handy.

While at this subject:

1. I often want to search for the same names or keywords in several editor tabs; I find it a bit clumsy that a find popup is linked to just one editor tab. For each and every tab I need to open a new separate find popup. Is there a way to keep that find popup around when opening a new tab, or switching tabs?
(I know, in each separate tab users might want different search terms. But maybe for a new tab, keep the find popup open, initialized with the search term of the previously visited tab. So each tab's find popup can still have different search terms.)

2. (Alternatively) Would it be possible to have a find toolbar in the editor, that stays open when switching editor tabs? (more or less along the lines of my Seamonkey browser, or Firefox etc.)

Philip Nienhuis <philipnienhuis>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Updated the item)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by philipnienhuis (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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-01-04 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2019-12-09 ttl StatusIn Progress Ready For Test
    2019-12-09 philipnienhuis StatusNone In Progress
    2019-11-16 ttl Assigned toNone ttl
        Operating SystemMicrosoft Windows Any
    2019-11-14 philipnienhuis Attached File- Added GUI_editor_find_popup.PNG, #47869

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code