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

[AntonyD]

Hi!
I know that each separate bug should be declared in separate topic - but in current case I don't know exactly how to divide it.
Very probably that One bug does exist only because another does exist. So еherefore, depending on from what description of the bug will start checking/testing and fixing - it may turn out that another bug will be unreproducible. BUT! IMHO - THIS fact should be obtained precisely targeted - trying to process ALL the descriptions of bugs provided further.

1) OK, let see on our initial sate of the patient: https://ibb.co/VSSv6T2
Here we open menu with listing of all opened TABs. So far all is good
Now let filter list - press 'B' key and get this: https://ibb.co/d2CW84Q
What’s already starting to get embarrassing at this point? I’ll be clear - we’ve got this menu on the left file panel. It seems logical to see the alignment of objects on the left side. BUT! This is the truth until if you became aware of the fact that the width of this menu can change - and do it dynamically!
Erase the letter B and enter the symbol * instead of it: https://ibb.co/3Mtsvm2
And we are surprised to see that the position of the quick search/filter field remained in place, but the called menu suddenly changed in size! Extremely! YES - the reason for this change we see immediately here - on the place: Instead of just TABs names, we now see complete paths to the directories that are opened in these tabs.

Again - like the change itself is logical - but it is illogical that since we have the probability/possibility of changing the size of this new menu, relative to which the quick search/filter field is displayed at the bottom, then the alignment of these two objects should be made as for the right file pane, so and for the left panel in the same way - on the right border of these objects ONLY!
And if plugin 'Quick Search eXtended' support also comes into play, then the situation with displaying objects relative to each other becomes even more terrifying: https://ibb.co/RS2KYsk
It is doubly terrifying - because if you open this menu on the right file panel, when the Total window is expanded to full screen, then when you call the quick search/filter field, you will see ONLY this gui-form, and its the "second part", represented by a gui-form from resources of plugin 'Quick Search eXtended' - will be drawn OUTSIDE the screen. Those it will be completely invisible....

This was a description of the 1 bug.

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.

3) This bug only affects the menu of recent folders and frequently used directories. The starting condition is the need to set many, many entries in the menu. So that there is a significant difference between showing a shorted version of lists and showing all entries. For another bug, this state was already in demand and was reproduced as I saw. Therefore, I do not worry about understanding this moment.
So - turn on the display of all entries - and now scroll this huge list to the bottom. This is our initial state of the patient will be.
Move the mouse cursor (and, accordingly, the selection/focus of the list's item in the menu) to the second entry from the list of frequently used directories. We keep count Up&Down from the separator of these two "half-lists"! Accordingly, the count goes up for the list of frequently used directories, and down from the separator goes the count for the last visited folders. Figuratively it looks like this:

Code: Select all

.........
    3
    2                           <------------- put selection/focus/mouse cursor on this list item - and DO NOT move it!!!!
    1
------------
    1
    2
    3
.........

And now simply press *. And 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!
Now to get a full description of the 3 bug - delete this * symbol. And yes, the records will come back, BUT!!! now I ask you to pay attention to the incorrect behavior and rendering of the scrollbar when repeating these two actions: entering * and deleting * and related to this - disappearing records and their re-drawing... The scrollbar will always be shown with the wrong height and with the wrong depth (here I do not know how to describe this concept - i.e. it is the amount to which the scrollbar can be adjusted to reach the end of the list. This is the space that is under the thumbtrack of scrollbar) that is expected for each current situation: when there are no records and when they do appear.

This seems to be all the description of all the bugs associated with this new menu/dialog.

[petermad]

I can confirm unexpected behavior when entering * in both Folder Tabs list and Directory History list

I can add a 4th bug:

In the Folder Tabs list I can use Ctrl+S to switch between filtering or not. But If I try do the same by clicking the Filter icon (at the right side of the search dialog) the whole list just closes - and the filter mode is not even changed when I reopen the list.

I do not see the same for the Directory History list. EDIT - it does happen here too, when the list menu´is narrower than the Quick Search dialog.

[AntonyD]

the whole list just closes

Yes, forgot to mention this.

I do not see the same for the Directory History list.

No - these GUI-elements are ALSO simply closing after my attempts to click on the 'SpeedButton' (now we know how internally this button is called)
AND for the Directory History list. It just won't happen on the first try, but on the second or third.
In the worst case (or is it considered the best attempt? who knows...) everything disappeared somewhere on the 10th click)))

P.S.
Perhaps I understood - when with 100% probability we get the closure of these objects - both the quick search/filter field and this menu itself.
This is if the field will be drawn under a long menu, even beyond the lower border of the main window of Total, drawn under the menu. Then clicking on the quick filtering button seems to "fall through" the borders of this GUI-form itself and "clicks" on the empty space OUTSIDE the borders of the main Total window.

[ghisler(Author)]

1) There is unfortunately no solution to that alignment problem: While I could move the location of the search dialog after expanding the list, I can't move the location of the quick search extended window.
2) This is intentional. You still search just in the name part, but you will see the whole path, which is useful when you have folders with the same name in many locations, e.g. c:\Documents\Smith\Letters, c:\Documents\Miller\Letters, c:\Documents\Someone Else\Letters, etc.
3) I can confirm that, very odd.
4) Currently clicking anywhere outside the history list will cause the list to close. I had to do this because users clicked on other apps, on TC etc. causing big problems. I will try to catch the click on the button.

[AntonyD]

1) There is unfortunately no solution to that alignment problem: While I could move the location of the search dialog after expanding the list, I can't move the location of the quick search extended window.

Didn't understand. This is primarily, of course, about only those built-in "GUI Total"s elements - which are controlled by you. This is a new menu and quick search/filter field. We will talk about additional elements belonging to the plugin 'Quick Search eXtended' a little later.
In the meantime, let's try again to understand - what exactly can not be done suddenly? So, once again - there is only a menu and a search field. The field will be attached to the ALREADY drawn menu. Simply FROM THE BOTTOM. And judging by the rendering behavior on the right file panel, we can say that mutual alignment is supported on the right side AND of menu border AND of search/filter field. Those no problem here? All well described and works quite correctly? Now let's analyze the situation when these objects are drawn on the left file panel (just as in my case). There now you just need to do exactly the same alignment along the right border of these two objects. Now it just simply doesn't exist. Can this be repeated? Or do we not know something about HOW this is done for the right file panel?

Now consider a situation where the menu dynamically changes in size. And.... and there are no more problems IF you do alignment on the right border of these two objects. Those even if and when the menu suddenly expands, it will do it to the left, and since the right border of the menu and the search/filter field will remain in place (aligned) - then there will be no more the described strange bug/behavior. Well, almost never will. Let's talk about the plugin field separately.

2) This is intentional.

Again Didn't understand. I will be able to use the ALL pathname in any way ONLY on the condition that the search string starts with the * character. Otherwise, the search works only on the last elements of the path. But I showed in the picture that I ERASED all the characters from the search, i.e. I INTENTIONALLY want to return to the original state of this menu - when only the very LAST elements of the paths = i.e. Tabs names = were displayed. Those this behavior cannot be YOUR intention - it MUST be mine - so that I can determine what exactly I want to look for and where. Therefore, I interpret the current behavior as a bug. Well, or how incorrect behavior.

And even if we consider your case of example - when on the tabs I see the heading "Letters" three times. After all - in order to go / search for the letters I need, I MUST enter the symbol * firstly - only then this search/filter will make sense. Because I will see all the paths. BUT! if for some reason I'm looking for NOT letters - then it's enough for me to enter a character from the tabname I need - and the FULL paths will only interfere with me. That is why, after working with the * symbol, I erased it in order to BACK to initial state of search and work with shortened paths - with tab names only! And I made for that veeeeeeeeeeery simple action - erased all input... And now it turns out that in fact I cannot do this - because you decided that this is the wrong behavior? Are you suggesting to CLOSE everything completely?! and open it again? Illogical, long, can enrage. Yes Yes. this might happen...

I will try to catch the click on the button.

Yes, please! And since we see that at some point, this click and the ability to work with a button on this field is, in principle, already possible now - it means that the only thing left is to guarantee all other cases that differ from the current support))) Even if it turned out to work purely by accident)))

[petermad]

2ghisler(Author)

Question:
Does the "Exact name match" setting in the Quick Search options apply to Quick Search in Folder Tabs list and Directory History List?

[ghisler(Author)]

About 3 I know now what happens: When you type a quick filter, TC will filter out all paths which do not match the filter. In addition to that, paths which appear both in the most frequently used section and the most recently used section will be shown only once. That's why some paths disappear.

Does the "Exact name match" setting in the Quick Search options apply to Quick Search in Folder Tabs list and Directory History List?

Yes it does!

[AntonyD]

In addition to that, paths which appear both in the most frequently used section and the most recently used section will be shown only once

Not a very pleasant addition, because I expect filtering ONLY from the characters entered in the corresponding field. And if I entered * - then it should mean the opposite - that so far ALL records that I see on the screen fall under the filter. And nothing should disappear.
And the fact that records can be repeated here and there is the natural order of things. 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.

[ghisler(Author)]

Not a very pleasant addition, because I expect filtering ONLY from the characters entered in the corresponding field. And if I entered * - then it should mean the opposite - that so far ALL records that I see on the screen fall under the filter. And nothing should disappear.

I can only write here why I added it: Before I removed the duplicates, it was quite confusing why a single result would often appear twice. I didn't notice it with the full lists of most frequently used an history present because the same path was buried somewhere in the middle of each list, but when only one result is remaining it's quite confusing. Maybe I should start filtering only when the user enters more than just an asterisk?

About 1 above: The main problem comes from the fact that the list of tabs is now displayed left-aligned to the mouse pointer when invoked with the mouse, but is expanded as if it were still right aligned (as when invoked via keyboard). I will change that. Please wait with further tests until the release of beta 6.

About 2: It is useful to search just in the name but see the whole path.

[AntonyD]

About 2: It is useful to search just in the name but see the whole path.

And I'm not saying that this action in itself is wrong. I'm just pointing out that to activate this, you MUST first enter the symbol * - and then enter the characters that will give the desired search / filtering result.
BUT if I ERASE everything, it means I switched to the state of the dialog "as if I just opened this very second." And in this state, only simple tab names are shown. Therefore, this output state(menu view/initial view) should simply be repeated.

[AntonyD]

it was quite confusing why a single result would often appear twice.

To be honest - again it is not clear: why? You have introduced two clearly separated concepts/lists: frequently used directories with the rank of their visits. And just a history of recent folder openings. It is perfectly reasonable for these lists to be crossed - i.e. have entries here and there. Just don't forget to insert a separator between the elements of the list when outputting. Those search results should NOT be displayed in some single / cross-cutting list. We are filtering/searching only in a holistic GUI object, which implies the output exactly always and everywhere - TWO lists/sections separated by a delimiter line.

[AntonyD]

Maybe I should start filtering only when the user enters more than just an asterisk?

And yes, of course, that's the only way. Entering this symbol simply turns on the special mode of further deep(fuzzy?) search/filtering. And therefore, with its input initially, nothing should change.

[petermad]

You have introduced two clearly separated concepts/lists: frequently used directories with the rank of their visits. And just a history of recent folder openings. It is perfectly reasonable for these lists to be crossed - i.e. have entries here and there

I fully agree - I would expect to the the filtered results in both lists.

[petermad]

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)

Confirmed fixed in TC 11.00b6

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)

Confirmed fixed in TC 11.00b6 - both for the Directory History list and the Folder Tabs list.