[TC 11.00b6] still Problems with new menu for TABS & HOT-DIRS

[AntonyD]

Yes. We continue discussion of this bug despite that fact what it was for unknown reasons moved to the Fixed section of the forum.
TS was me - I did not confirmed all part were fixed but bug "is fixed"))). SO let's open these next bugs as a new ones(((

1)
05.06.23 Fixed: Quick filter in history: Only start filtering when the user types more than an asterisk * , so folders present in both lists will not be hidden initially (32/64)
As for this fix. The original problem stated that after pressing *:

you will be amazed to see the mysterious disappearance in the list of last-visited folders some of these records. For example, I had initially 21 entries, and after clicking * I received only 9 entries in this second "half-list". Logically, the symbol * should not have given any cut-off, because it is intended to provide a more COMPLETE search/filtering of the characters that WILL be entered AFTER it!

That what was expected to be treated like a fix - the calling process of the quick search/filter field by pressing the * button (NOT depending on the number of button presses *) will simply open this new dialog at the bottom of the open menu and NOTHING else will happen!
And now we have a forced scrolling^ of the list to the beginning (once again - it is understood that we are checking a bug on a veeeeeery long list/menu), and there IS still some change in both the number of entries and the size of the scroll area when typing ** or ***. Maybe it's worth introducing control at least for the possibility of input of this char as the first one?

P.S. (^)Autoscroll is performing to the top and this despite the fact that in the settings I have Scroll list [to the bottom]!
But I didn't write this because I want a correction to the correct direction of scrolling - no, I believe that such scrolling should not exist at all in these circumstances!

Also I wrote such thing in prev.topic:

Just remember to show the same separator between the results after filtering - to make it clear that the same folder/path was found - just one entry is in the top list - in the frequently used directories, and the second entry - is in the list of recent visits history.

And indeed - despite the fact that I just need some expected unambiguous search/filter result - I want to see which of the two sections it belongs to. Those If the first section did not give a result, then it is empty, then comes the separator, then comes the result from the second section of the stories menu. There is nothing wrong with the fact that suddenly this separator will "fly" through the menu. Everything is adequate and quite expected - because in this menu, in principle, two entities are always displayed: frequently used directories and the history of recent visits. And they are separated. Now yet this separator is not presented in the search/filtering results - But I'm looking forward to it!

2)
05.06.23 Fixed: New history window: Clicking on filter button (funnel icon with text "Ctrl+S") in quick search would close the history immediately (32/64)
It looks like it's solved for the short menus only. Which never go beyond the main window of Total (EVEN taking into account the height of the quick search/filter field) with all borders. When I tested just such short menus, it seemed that clicking on the button worked adequately.
But look at the following screenshot: https://ibb.co/GxxCqk2
It highlights the area of the new menu marked in red. This is a special area with an arrow, with which you can scroll through this list without resorting to the built-in scroll bar. Do you also remember about the bug associated with it, which, it seems, can only be fixed in Windows itself by Microsoft themselves?
So you're drawing a quick search/filter field NOT taking this special area into account! See how this field partially overlapping menu's bottom including its special area? So if you poke the mouse on the button in this area: https://ibb.co/487hHth
you will receive in fact scrolling of the menu. Because a mouse click in this area (look at the tip of the cursor!) seems to "fall through" this button.

P.S. Another manifestation of this bug is the fact that in 32-bit Total - only in it - if I call this menu and then press *, and then click outside the area of this menu - the click will "fall through" even outside of the main Total window, which is supposed to be figuratively under this menu at this time. And it activates the previously launched application that is already BELOW the Total window and whose working area of the window is in the focus of the mouse click. The same problem and with ALL_TABS new menu!

3)

2) And this bug is more simple. It lies in the fact that we CANNOT go back to a shortened version of this menu when ONLY tab names are present in it. Those even if we erase the entire input in the search/filter field, then nothing changes in the form: https://ibb.co/X42tJCR
Unexpected and uncomfortable.

It's still here and I still believe that such non-revertable case should not exist...

[ghisler(Author)]

1) Quick search always scrolls to the first match, which is the first entry when type just an asterisk. Is this bad?
2) This special area is for scrolling with mouse clicks. There is no need for it while the quick search dialog is up, that's why quick search is shown directly below the last path name.
3) I have already explained that this is intentional.

[AntonyD]

1)
Yes. Let me try again to clarify my point. The fact of typing the character * in the field - in fact, could be beaten by the presence of a new "fuzzy search" checkbox on the form. Because, in fact, that's the way it is: the input of this ONE! character * simply turns on this mode, and the input of subsequent characters (among which the input another * should already be prohibited) just turns on the search for these characters among the entire data set (list of paths). Therefore, I do not expect any scrolling of the list (any actions with it), because I still do not actually enter the very characters which I want to look for!!! Those only after entering the desired characters we can agree that the menu will undergo changes both in size - and in the number of displayed information. Moreover, the "disappearance" of any lines will only now be perceived as a logical action, because I will enter REAL characters that are present in the visible source data (list of paths).
And now, after just the second * - suddenly disappear in a huge number of lines. What is this? Do you think everyone will remember that this was done on purpose and for their convenience? A pier, there is a clearing of the repeating data?
So I repeat here - that the repetition of lines with paths in these two sections is normal! And the search/filter should handle those sections on its own. And if each section contains a suitable entry, then it is displayed. Only a separator remains between the sections.

P.S.
And by the way! there was no such auto-scrolling in the previous beta4/5. Otherwise, I would have already described this bug in my first post on this topic, which was closed as "fixed")))

2)

that's why quick search is shown directly below the last path name.

I'm sorry. I'm very sorry in advance. BUT I can't help but regard it as just a joke after a hard day's work.

ANY extra object that needs to be associated with this new menu - can't NOT take into account ALL of its dimensions!
Including such special elements that occur under very special conditions. Such as this special strip with an arrow for precision scrolling.
Therefore, just please return access to this area and make sure that the button's click on the quick search/filter field does not "fall deep" in the area where I indicated in my screenshot.
Although it is very likely that once you take into account this area and lower the field below - this fix will happen by itself.

3)
I have read your solution. But I don't understand why this can't be implemented as an option under the user's decision?
Still, I personally use this functionality and its current behavior makes it necessary to simply close it after removing everything from the field,
close the menu and reopen the menu to see the actual menu with a list of all tab titles. Is it SO done for the convenience of the user or what?


P.P.S.
btw did you manage to reproduce the bug with "click outside the area of this menu" on TC-32bit?

[ghisler(Author)]

btw did you manage to reproduce the bug with "click outside the area of this menu" on TC-32bit?

I tried to reproduce what I could with the limited information you gave, but no click was registered elsewhere. Please submit a new separate bug report with details on how to reproduce it.

[AntonyD]

Please submit a new separate bug report with details on how to reproduce it.

Okay, for a simpler, single-bug, problem description, I’ll create a post. But I just want to say - I don’t know - WHAT NEEDS TO BE DESCRIBED IN MORE DETAIL, because i have described absolutely all conditions for its reproduction.

And the other bugs in this topic of mine - from the first post - did you manage to reproduce them?

[ghisler(Author)]

And the other bugs in this topic of mine - from the first post - did you manage to reproduce them?

I have replied why I don't think that your reports 1..3 are bugs.
Some more details of why I think that 3 must be the way it is now:
When you press Ctrl+Shift+A, the list shown is the list of tab titles. As you know, it's possible to rename tabs, so the title may not be the last part of the path.
Typing a * in quick search shows the actual paths, and searches anywhere inside of them.
Removing the * still shows the paths, but search will then be done in the last part of the path. This wouldn't be possible if removing the * would revert to the shorter version.

[AntonyD]

2ghisler(Author)

I have replied why I don't think that your reports 1..3 are bugs.

Those:
on 1) point:
fundamentally allowed input of the second and further symbol * - and the operation of repeated values auto-hiding ​​ONLY in the second section of this 'DIR-history' menu and plus auto-scrolling the list up (although the user deliberately lowered it down) - is this normal and will it be convenient and logical for users? And it's not a bug?
Please answer Yes/No on these 2 questions.

And the fact that the found paths will simply be displayed without clarification - in which of the two sections a match was found (the section separator will not be used) - is it convenient and logical for users? And it's not a bug?
Please answer Yes/No on these 2 questions.

on 2) point:
https://ibb.co/487hHth
Those a right-click, performed while the cursor tip is in the specified area in the screenshot, and its unexpected result in the form of scrolling through a very long list of entries in the menu in the background - is it convenient and logical for users? And it's not a bug?
Please answer Yes/No on these 2 questions.

Not taking into account the fact that the menu can be longer by a special area (https://ibb.co/GxxCqk2 - red area and its continuation, hidden under the quick search/filter box) with an arrow for precision scrolling a long menu, Or even vice versa: purposefully ignoring that area - it's not a bug?
Please answer Yes/No on this 1 question.

on 3) point:
I still don't understand why this can't be implemented as an option under the user's decision? Yes, I prefer to clear the search filter and revert back the initial visual style of the 'All-TABs-list' menu.

Also Your example is accepted and its essence does not prevent the desired behavior released under the custom option. In addition, it has one small logical omission. If a person is looking for something from memory in a large list of open tabs (even those with renamed names) and the sought-for is NOT in the short version of the menu - he will press * and repeat the search & will find what he want. A THEN there is no need to continue the search - because there will be performed a "jump" to the found tab. But if for some reason user need to continue the search - nothing prevents him from erasing the search symbols - EXCEPT the first asterisk - and restart the search/filtering process. But if the user COMPLETELY & purposefully erases ALL symbols in this field - is that something and should additionally mean? Or is it not taken into consideration at all? Is it simply regarded as a user error or something similar? And that's why nothing gets done?

[ghisler(Author)]

1) I understand your point, and I think I can stop the filtering, but it will be inconsistant with typing anything else - oh well.

2) The quick search in the main window is also shown directly below the file names, not below the main window.

3) People may want to search in the real directory names, not just in the tab titles. I could add an ini option, but why? Just press ESC and Ctrl+Shift+A again.

[AntonyD]

2ghisler(Author)
in fact, you did not give Yes / No answers on any of the points .. It's strange somehow. We ask this not just like that - but in order to accurately understand your position and logic.

Returning again to the 1st point: It describes FIVE strange behaviors. Your answer partially covers only two of them.
Let's go over the details again, shall we?
1a) on entering the first character *, an unnecessary forced scrolling of the entire long list in the menu to the top is triggered
1b) in principle, the input of two or more characters * in a row is allowed.
1c) on entering the second character, an unexpected auto-hide of duplicate entries is triggered
1d) hiding records only works for records in the second section
1e) and the output of the search/filtering results is issued without any clarification - in which of the two sections it was.
There is no stable visual list separator, even for the case of a degenerate empty result - when there is no match anywhere.

Your answer can probably be drawn to 1b) and 1c) - but you will agree that this is an inexact match.
It is not a question of banning any filtering, but of elaborating all the implicit paragraphs above.
Namely:
1a) No autoscrolling of the list, the user has already decided himself - where should be the caret in the list - he has selected the desired entry with focus. Or vice versa - no entry is highlighted, but also nothing else he expects, what can happen with the position on the list, or with the list itself.
1b) only one and only the symbol * at the beginning is allowed. Further of course * can appear between other symbols - but again only one symbol between two others.
1c) This item will not require any control/intervention/corrections because it will become impossible after editing for paragraph 1b) above - the second symbol * in a row will simply not be able to enter.
1d) Also - nothing to do, because the behavior for item 1b will be fixed)
1e) when there is a filtering results - if there is a match in the section of frequently used directories and in the history of recent visits - you should show both entries - just between sections (as at the first opening of this menu) - the delimiter will be drawn - and we realize that the result is there and there.

2) We can't compare the rendering behavior of this "quick search" field with the specified other example of its use - because they are completely different neighboring objects. And in your example - this object has eternal, clear boundaries and sizes. It will not be increased by the size of some special area. And I described the incorrect behavior of precisely for the rendering of this field after the new menu. And because this is a new menu, a new object - the rules for drawing the objects accompanying it - will also be new))))) This is logical.

3) Maybe we are still misinterpreting the phrase "SEARCH from memory"? Once again - if a person knows exactly which name from the ALL-TABs list he needs - he will do IMMEDIATELY an exact search - WITHOUT entering * as the first character. And so we get headline searches. IF he does not remember the exact name - but we understand that he will find it on a whim, entering approximate characters from the name OR from the folder name (for the case when the tab name for the folder differs from the real end-folder name, based on its full path on the disk) - then for this he as a FIRST character enters '*'. And only after - he will start typing and selecting other characters to get what he is looking for. And in this case, those very real names will be searched for. Those, EVERYTHING you described already exists and works. And with this input, the characters that stand AFTER the first and eternal character * are erased and entered. Otherwise, we will not get a LIVE and fuzzy search - because again - the user does not exactly remember this name.
BUT even if he remembers! And this is the real name of the end-folder, which has a completely different name in corresponding tab - the user will not work with the quick search/filter field like this: first '*' is entering to activate the display of FULL and REAL paths to folders, then '*' is erased so that the user enters instead of the '*' - the symbols from exact known name of the target folder, in order to quickly weed out exactly this folder, represented in the ALL-TABs list by the changed name. This is illogical. Then for this it is MORE LOGICAL to make one more BUTTON on the quick search/filter form, so that you can enable/switch/disable the MODE(s) of this tool. So that you do not have to think about the fact that the first character can be simply only a special character that changes the logic of this tool according to some rules - and that's all what it does.

[ghisler(Author)]

1a) Each change of the quick filter text causes a filter operation, which also places the cursor on the first match. This also happens when you enter a single asterisk. This is done because the user may have had a different filter before and replaces it with a single asterisk. It would indeed be better to treat a single asterisk the same as an empty filter box, I just described why it reacts as it does now.
1b) I'm currently not limiting the input as long as the filter matches at least one entry. The user may want to enter two asterisks to then put some text in between them, e.g. when he uses an on screen keyboard where he has to switch between letter input and special character input. I do this often on Android.
1c) This is intentional and will not be changed. When the user searches for a certain path, he does not need it twice.
1d) It goes through the list, so clearly entries which appear a second time would be in the second section
1e) You can still see the counter on the right even after filtering

2) I wonder what you need that scroll down button for during quick search. It just doesn't make any sense to me why you would need it.

3) Sorry, I will not add another button to quick search.

[AntonyD]

It seems that the whole topic will be dropped into the section "TC Behaviour which will not be changed" very soon

P.S.
3) - I DID NOT suggest to add an additional button;)) I just used this possibility as an explanation to these actions which have place in nowadays:
" the fact that the first character can be simply only a special character that changes the logic of this tool according to some rules - and that's all what it does." = Input of single * as 1st char - it's just a radiobutton in fact "use fuzzy search, or not".

2) ALL lists to begin with they are scrolled by me to the bottom, then it can be scrolled a little higher - depending on the circumstances and the essence of the list. I always need to first evaluate ALL options at least "diagonally" / selectively piecewise.

1<all>)
Let it be so)))
In the end, it's always easier to just not use this functionality than to suffer from uncomfortable behavior every time.

[AntonyD]

https://imgur.com/a/ERYYcUB
You will be notifed about very strange things)))
Simply click "I am" - and you will see the bug - exactly as I see it.
4 sec - opened quick search/filter field
till 9 sec I show - all areas - on which we should pay attention
10 sec - first click - you even will hear it! And you will see the bug essence.
I am pressing the button - but scrolling of the list below is performing instead of accepting the button click. Till 12 sec.
After that I am manually scrolling up to the top again the list and from 15 sec trying again to simply click on a button... And getting again
completely undesirable and unexpected scrolling...
And one repeat again after that will follow on this short movie.

[ghisler(Author)]

Sorry, I have only kept this thread here for 1a), which I have changed in beta 7. I will not change the other things you complained about because I don't see the point. No one else has complained about them either.

[AntonyD]

Others may not notice this bug, but I found it and show it to you. The video is quite clear - I click on the button on the form, and the action is performed with the special area of menu called previously on the background of this form. There's an obvious bug on the face - the processing is on the wrong level. It's simple and straightforward. Or do I need to go into more detail about what the problem is?

Did you watch the video at all? A straightforward question, by the way.

[ghisler(Author)]

That seems to be yet another unrelated bug. Why? Why do you put it all in one thread? I can't work like that!