Changes in "Search Results" window

[Martin_fr]

By the way, the tab control buttons really look very strange to me. As many as five buttons to close tabs! Are they really needed there? The tab is easily closed by pressing the middle mouse button or [Ctrl+F4]. This window can have many tabs, but not so much that you need a whole panel with buttons to close them. Although, of course, they do not interfere with anyone.

They are from December 2019 by BrunoK.
I admit I don't personally use them but they don't bother me either.

The "Close all" is a tremendous help. Wouldn't wanna miss it.
The "Close others (both sides)" => occasional.

While I don't use, I can see good reason for "close all left", i.e., all older searches.
I have often enough had a dozen result tabs. And it becomes a bit of work to manage.

We can add another checkbox that will display not only the search text but also the path in the tab caption.

What if the path is long?
An ideal solution would be a 3-state RadioButton but it does not fit here.
Somehow the full path must be supported as there are use cases that require it.
An easy solution for now would be to switch between full path and relative path with the current button, instead of between relative path and no path. Then the "no path" option would be left out.
@n7800, will you look at this issue?

To be honest, I don't think that should be a button at all. Especially, when there already is a question about how many buttons there should be.

Imho this should be an option, in an option dialog.
Maybe with a quick toggle via the context menu. (I.e. the menu could have a direct toggle entry "Show path" / "Show full path" or a submenu.

But then the setting should be persistent. If persistent, you set it once, you need no quick access.

Btw, the "path is long" has always existed... And now that the path is no longer in front of each result line, that is no problem. There is space in the header line (it only has the path).

[JuhaManninen]

To be honest, I don't think that should be a button at all. Especially, when there already is a question about how many buttons there should be.

Imho this should be an option, in an option dialog.
Maybe with a quick toggle via the context menu. (I.e. the menu could have a direct toggle entry "Show path" / "Show full path" or a submenu.

Context menu sounds good. It could have 3 RadioItems, "Full path", "Relative path", "No path". It should affect per tab. The current button seems to affect all tabs.

But then the setting should be persistent. If persistent, you set it once, you need no quick access.

Default values should be in the global options dialog and be persistent. A context menu could still override those defaults.

Btw, the "path is long" has always existed... And now that the path is no longer in front of each result line, that is no problem. There is space in the header line (it only has the path).

n7800 suggested showing the path in a tab's caption which could become uncomfortably wide.

[Martin_fr]

n7800 suggested showing the path in a tab's caption which could become uncomfortably wide.

Big NO.
I wouldn't even think of an option for that.

It could be in the Windows title bar. Though that is "unconventional", statusbar (if added) would be the place.
Anyway, this may work for some, it wont work for me. Just to far to look. If it is in the search result, it is right there.
Also title bar may be awkward in a docked ide.

[BrunoK]

The "Close all" is a tremendous help. Wouldn't wanna miss it.
The "Close others (both sides)" => occasional.

While I don't use, I can see good reason for "close all left", i.e., all older searches.
I have often enough had a dozen result tabs. And it becomes a bit of work to manage.

Do agree with Martin_fr RE relative usefulness of the various close buttons.

Now, after testing, and modifying a bit the code submitted by n7800
I propose to use the newly added button to circularly toggle thru 3 presentations.
0 - full path on the filename line.
1 - relative path
2 - filename + relative path if line selected.

I really like the enhanced backup folder visibility.

0 - full path image attached and patch file searchresultview_bk

[n7800]

An ideal solution would be a 3-state RadioButton but it does not fit here.
Somehow the full path must be supported as there are use cases that require it.
An easy solution for now would be to switch between full path and relative path with the current button, instead of between relative path and no path. Then the "no path" option would be left out.
@n7800, will you look at this issue?

I do not see any problem - you can just change the style of the button to tbsButtonDrop in which there will be a list of possible options. A hotkey (Ctrl+P) will simply switch modes in a circle. I have already implemented it, and I am finishing the "Refresh" button.

But BrunoK is very fast )). Let's give each other time to respond, so as not to do the same thing...

[n7800]

n7800 suggested showing the path in a tab's caption which could become uncomfortably wide.

I agree, it was just an example. The point is that my search paths are short "c:\laz\ide", "c:\laz\components", and I immediately close unnecessary tabs.

I also thought about a tab hint, but will have to wait for it to show up...

That's why I like the status bar suggestion. In addition, it can display a lot of additional information. For example, it is better to display the number of results there, and not in the tab title. You can also show the number of filtered items there, etc.

[BrunoK]

Around line 1221 of searchresultview.pp, replacing

Code: Pascal  [Select][+][-]

1.       // draw found text
2.       { if [cdsSelected,cdsMarked] * State <> []
3.         then DrawNextText(lPart, clHighlightText)
4.         else DrawNextText(lPart, clHighlight); }

by

Code: Pascal  [Select][+][-]

1.       DrawNextText(lPart, clNone, [fsBold]);

while less fancy may be more solid across widget sets and color scheme.

[Martin_fr]

Around line 1221 of searchresultview.pp, replacing

Code: Pascal  [Select][+][-]

1.       // draw found text
2.       { if [cdsSelected,cdsMarked] * State <> []
3.         then DrawNextText(lPart, clHighlightText)
4.         else DrawNextText(lPart, clHighlight); }

by

Code: Pascal  [Select][+][-]

1.       DrawNextText(lPart, clNone, [fsBold]);

while less fancy may be more solid across widget sets and color scheme.

Well we could keep the color, but add fsBold (in both cases).

[BrunoK]

Well we could keep the color, but add fsBold (in both cases).

Yes,

Code: Pascal  [Select][+][-]

1.       // draw found text
2.       if [cdsSelected, cdsMarked] * State <> [] then
3.         DrawNextText(lPart, clHighlightText, [fsBold])
4.       else
5.         DrawNextText(lPart, clHighlight, [fsBold]);

looks alright.

and shows
I also propose to modify the line number color on the selected row. I just fell on a case where I wanted to check the locality of 2 different search terms in the same file and lacking contrast made it annoying. Modifying

Code: Pascal  [Select][+][-]

1.     // draw line number ("99999: ")
2.     { ~bk }
3.     if [cdsSelected, cdsMarked] * State <> [] then
4.       DrawNextText(lPart, clNone) // ??? Let system determine contrast
5.     else
6.       DrawNextText(lPart, clGrayText);

made it more confortable.

[JuhaManninen]

I applied the patch from BrunoK with some modifications.
I fixed a range overflow when FFilePathShow went over High(TFilePathShow). The code was logically correct but it is good to make it work without range errors.
I added a bold modifier for found text.
I changed the GUI hint text a little. Now it says " (Ctrl+P)" instead of "- Ctrl_P".

It looks good to me now. Easy and intuitive. Please test.

[Edit] I applied the line number color change from BrunoK. Yes, looks much better.

[n7800]

I even know the hotkey for this function - [F5]. Maybe I'll add it one of these days.

I do not see any problem - you can just change the style of the button to tbsButtonDrop in which there will be a list of possible options. A hotkey (Ctrl+P) will simply switch modes in a circle. I have already implemented it, and I am finishing the "Refresh" button.

But BrunoK is very fast )). Let's give each other time to respond, so as not to do the same thing...

I seem to have made it clear that I am working on a patch...

I also found some redundant methods and found a couple of bugs.

[Martin_fr]

Their is an issues with painting....

I searched for "create" and one result has the word "created".

On the first (new) their is a 1 pixel gap after the bold text. Looking at the old (2nd image) result (which also did bold) => there is no gap.

My guess is, that when you measure, you need to measure without bold style.

[BrunoK]

Replace line 1162 of latest trunk

Code: Pascal  [Select][+][-]

1. inc(lTextX, lTree.Canvas.GetTextWidth(aText) + 1);

by
   

Code: Pascal  [Select][+][-]

1. inc(lTextX, lTree.Canvas.GetTextWidth(aText));

Sorry I havent figured out how to generate a GIT patch on git downloaded source.

[n7800]

I've added a new patch to the bugtracker. Please check, it includes a lot of new stuff. Details in the same issue: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40286#note_1418757952.

[n7800]

Code: Pascal  [Select][+][-]

1. inc(lTextX, lTree.Canvas.GetTextWidth(aText) + 1);

I added this because I noticed in some cases that the letters overlap each other by one pixel (in Windows 7/8.1). Maybe it's a font smoothing issue.
It really can be removed, it looks good without it. But only after deciding to accept my previous patch...