! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Make the Ctrl+F search dialog like Firefox
Status:
RESOLVED: FIXED
Severity:
enhancement
Product:
Xfce4-terminal
Component:
General

Comments

Description Far223 2019-02-06 18:08:12 CET
 
Comment 1 Far223 2019-02-06 18:16:05 CET
Hi, I would like to make a feature request about the search dialog.
I find it bothersome to have this window pop up in the middle of the terminal, potentially hiding text. I suggest that it be transformed into a bar at the bottom exactly like in Firefox.
Furthermore, it would be great to have "Wrap around" enabled by default because it is more practical.

Thank you very much for your attention and your work.
Comment 2 Git Bot editbugs 2019-02-06 18:46:36 CET
Igor referenced this bugreport in commit 359cc1b6bfea4519611796fbf43e6ad99bda94f6

Enable "Wrap around" by default in the search dialog

https://git.xfce.org/apps/xfce4-terminal/commit?id=359cc1b6bfea4519611796fbf43e6ad99bda94f6
Comment 3 Igor editbugs 2019-02-06 18:52:57 CET
Thank you for your suggestions!

I've pushed a change to enable "Wrap around" by default.

I'm reluctant about your another request. Having a search panel pop up at the bottom (or at the top) of the window would hide some portion of the terminal contents the same way it does now - or even worse as a dialog can be moved while a popup panel would be stuck in its position. 
Which is why I believe some users would like to keep the current behavior so I'd probably end up adding a configuration setting and supporting both ways of displaying the search widget - the existing one and the one you're proposing.

How bad is the current dialog for you?
Comment 4 Far223 2019-02-07 08:40:03 CET
Thank you for your reply. I could argue that a bar at the bottom only hides one or two lines which we can scroll to see, whereas the current search dialog partially hides several lines, especially when the window is not maximized since a line is more likely to reach the middle of the terminal.

Of course the bar I suggest should not move the text on the screen when spawned, it should appear above the last line, and the user can then scroll down if his prompt happens to be on the last line.

By the way, the bar I'm suggesting is also the same as in Mousepad, so maybe it can also be viewed as unification across Xfce.

Thank you very much for your attention
Comment 5 Far223 2019-02-07 09:08:48 CET
Also, the keyboard shortcuts "<Actions>/terminal-window/search-next" and "<Actions>/terminal-window/search-prev" in ~/.config/xfce4/terminal/accels.scm do not work in the Ctrl+F window, you have to focus the terminal window.
Furthermore, these two keyboard shortcuts only work after having pressed Previous or Next at least once with the mouse.

(Also, the "Wrap around" box setting only propagates to these two keyboard shortcuts after having pressed Previous or Next with the mouse:
- begin a search without wrap around, click on Previous or Next, now if you focus the terminal window the two keyboard shortcuts work as expected.
- now click on "Wrap around", focus back the terminal window, the search doesn't wrap around with the keyboard shortcuts.
- now click on previous or next, and now the keyboard shortcuts wrap around

This is such a little detail, and I won't ever use the search without wrap around, so I don't ask that you fix this last one.)
Comment 6 Igor editbugs 2019-02-07 15:25:02 CET
(In reply to gerzgzefezfzefadz from comment #4)
> Thank you for your reply. I could argue that a bar at the bottom only hides
> one or two lines which we can scroll to see, whereas the current search
> dialog partially hides several lines, especially when the window is not
> maximized since a line is more likely to reach the middle of the terminal.
> 
> Of course the bar I suggest should not move the text on the screen when
> spawned, it should appear above the last line, and the user can then scroll
> down if his prompt happens to be on the last line.
> 
> By the way, the bar I'm suggesting is also the same as in Mousepad, so maybe
> it can also be viewed as unification across Xfce.
> 
> Thank you very much for your attention
I'm not sure whether the terminal could use the same approach for the search bar that Mousepad is using.

In Mousepad, opening a search bar reduces the view area (which is displaying the text). In the terminal, that would mean changing the terminal widget size which would result in changing geometry for the app that is running inside, and not all apps would be able to handle this.

Again, I believe not everyone would be happy about such changes so I'd have to keep the old approach as an option.
Comment 7 Igor editbugs 2019-02-07 15:32:42 CET
(In reply to gerzgzefezfzefadz from comment #5)
> Also, the keyboard shortcuts "<Actions>/terminal-window/search-next" and
> "<Actions>/terminal-window/search-prev" in
> ~/.config/xfce4/terminal/accels.scm do not work in the Ctrl+F window, you
> have to focus the terminal window.
> Furthermore, these two keyboard shortcuts only work after having pressed
> Previous or Next at least once with the mouse.
> 
> (Also, the "Wrap around" box setting only propagates to these two keyboard
> shortcuts after having pressed Previous or Next with the mouse:
> - begin a search without wrap around, click on Previous or Next, now if you
> focus the terminal window the two keyboard shortcuts work as expected.
> - now click on "Wrap around", focus back the terminal window, the search
> doesn't wrap around with the keyboard shortcuts.
> - now click on previous or next, and now the keyboard shortcuts wrap around
> 
> This is such a little detail, and I won't ever use the search without wrap
> around, so I don't ask that you fix this last one.)
This is a good catch!

The prev/next shortcuts are indeed part of the main window - this allows "Find Next" and "Find Previous" menu items to work.
I will see if it's possible to propagate the shortcuts to the search dialog but that might not be trivial.

The second part is actually also related to the shortcuts. The thing is that the shortcuts (i.e. the menu items, essentially) and the search dialog buttons have different "on click" handlers. Only the dialog buttons' handlers will react to changes in the search settings; the menu items will simply reiterate a search pattern that has been previously set by clicking a dialog button.
Again, I will look into this but cannot guarantee a quick fix.
Comment 8 Git Bot editbugs 2019-02-07 19:53:04 CET
Igor referenced this bugreport in commit 78bc0cca335ae623c4ec47facd6f673848072d84

Make "Find Next"/"Find Previous" menu items respect search settings

https://git.xfce.org/apps/xfce4-terminal/commit?id=78bc0cca335ae623c4ec47facd6f673848072d84
Comment 9 Git Bot editbugs 2019-02-08 03:27:52 CET
Igor referenced this bugreport in commit 5093b0831ab8eb7e47d8c1064ec986c615af9dca

Make search dialog buttons use menu item accelerators

https://git.xfce.org/apps/xfce4-terminal/commit?id=5093b0831ab8eb7e47d8c1064ec986c615af9dca
Comment 10 Far223 2019-02-16 18:38:12 CET
I also have to add that it is practical when the search dialog moves with the terminal window instead of having to move around two windows.
But searching in vte is flawed as I outlined in the two bugs you rightfully closed (the same happens in gnome-terminal of all things), so this change to the search UI I'm suggesting isn't very useful until upstream fixes those issues. I generally copy the output in a text editor to Ctrl+F on it.
Comment 11 Far223 2019-02-22 10:53:33 CET
One last idea: there could be an option to set the opacity of the search bar/window, it wouldn't hide any text like that. Furthermore, it solves the problem of

> In Mousepad, opening a search bar reduces the view area (which is displaying the text).
> In the terminal, that would mean changing the terminal widget size which would
> result in changing geometry for the app that is running inside, and not all apps
> would be able to handle this.

because the search bar would be above instead of occupying new space.
Comment 12 Igor editbugs 2019-02-22 15:09:55 CET
(In reply to gerzgzefezfzefadz from comment #11)
> One last idea: there could be an option to set the opacity of the search
> bar/window, it wouldn't hide any text like that. Furthermore, it solves the
> problem of
I think this is a good idea.
Unfortunately, GTK doesn't seem to allow setting opacity for window decorations so the search dialog with opacity set to 50% ends up looking like this: https://i.imgur.com/I2nt0On.png
Comment 13 Far223 2019-02-22 17:01:45 CET
I guess client-side decorations could do the trick, but this is controversial.
Comment 14 Igor editbugs 2019-02-24 16:17:21 CET
How about this one? https://i.imgur.com/tLlEzPR.png
Comment 15 Far223 2019-02-24 20:14:49 CET
This is great, thank you.
Of course, this requires a compositor.
Now I suggest an horizontal GtkScale in the search window to adjust its opacity, and the opacity should be remembered.
Comment 16 Git Bot editbugs 2019-02-26 16:06:20 CET
Igor referenced this bugreport in commit 71ce45e8ffb62c2462b335ee9298039b5d24b51b

Allow to set opacity of the Search dialog

https://git.xfce.org/apps/xfce4-terminal/commit?id=71ce45e8ffb62c2462b335ee9298039b5d24b51b
Comment 17 Igor editbugs 2019-02-26 16:07:07 CET
(In reply to Far223 from comment #15)
> This is great, thank you.
> Of course, this requires a compositor.
> Now I suggest an horizontal GtkScale in the search window to adjust its
> opacity, and the opacity should be remembered.
Here you are!
Comment 18 Far223 2019-02-26 20:36:16 CET
Thank you very much.
Testing it, I found that for each new terminal window, the opacity setting is not applied to its search dialog until the value of the GtkScale is changed by the user.
Also, the minimum opacity possible should be approximately 10 %, or the user might loose the window because it becomes totally invisible.
Comment 19 Igor editbugs 2019-02-26 21:05:36 CET
(In reply to Far223 from comment #18)
> Thank you very much.
> Testing it, I found that for each new terminal window, the opacity setting
> is not applied to its search dialog until the value of the GtkScale is
> changed by the user.
It works for me - this line here makes sure that the opacity setting gets applied each time the dialog gets open: https://git.xfce.org/apps/xfce4-terminal/tree/terminal/terminal-search-dialog.c#n359

> Also, the minimum opacity possible should be approximately 10 %, or the user
> might loose the window because it becomes totally invisible.
This makes sense. I've made the change, thanks!
Comment 20 Far223 2019-02-27 10:54:34 CET
Testing in a Manjaro Xfce VirtualBox VM, I found what was wrong using this script:

#!/bin/python
import gi
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk
win = Gtk.Window()
bar = Gtk.HeaderBar()
win.set_titlebar(bar)
Gtk.Widget.set_opacity(win, .7)
win.show_all()
print("Opacity: ", Gtk.Widget.get_opacity(win))
Gtk.main()

If set_opacity is before show_all, the window appears not transparent at all, even though its opacity is correctly set. The opacity works correctly if set_opacity is after show_all.
Comment 21 Far223 2019-02-27 13:28:48 CET
This happens because Manjaro uses gtk3-classic aka gtk3-mushrooms, which is a patched version of gtk3 for classic desktops:
https://gitlab.manjaro.org/packages/extra/gtk3-classic
https://github.com/TomaszGasior/gtk3-mushrooms

The GitHub page says that "CSDs are totally disabled by default". CSDs may be disabled, but I can confirm that the transparency of the title bar works all the time on a default Manjaro if set_opacity and show_all are swapped.
Comment 22 Igor editbugs 2019-02-28 18:14:15 CET
(In reply to Far223 from comment #21)
> This happens because Manjaro uses gtk3-classic aka gtk3-mushrooms, which is
> a patched version of gtk3 for classic desktops:
> https://gitlab.manjaro.org/packages/extra/gtk3-classic
> https://github.com/TomaszGasior/gtk3-mushrooms
> 
> The GitHub page says that "CSDs are totally disabled by default". CSDs may
> be disabled, but I can confirm that the transparency of the title bar works
> all the time on a default Manjaro if set_opacity and show_all are swapped.
As if supporting various GTK versions wasn't enough pain, the distros are now using patched versions of GTK...

I've pushed another change, please verify that it works correctly.
Comment 23 Far223 2019-02-28 20:58:06 CET
Everything works fine on Manjaro now.
Comment 24 Igor editbugs 2019-02-28 20:59:22 CET
Great! Can the bug be closed?
Comment 25 Far223 2019-02-28 22:01:06 CET
The bug can be closed. Thank you for everything!
Comment 26 Igor editbugs 2019-02-28 22:03:26 CET
(In reply to Far223 from comment #25)
> The bug can be closed. Thank you for everything!
Thank you for your ideas on improving the search dialog!

Bug #15124

Reported by:
Far223
Reported on: 2019-02-06
Last modified on: 2019-02-28

People

CC List:
0 users

Version

Version:
0.8.7.4

Attachments

Additional information