First, let me say that I "could not live without" QF Pro. It is excellent. I have multiple QF Pro licenses for the different seats/users in our office.
Second, let me explain that I am still using an older version of QF because I am still using an older version of TB... because I have not been willing to risk updating TB and then losing the mission-critical functions of QF because of the constant TB updating major changes to their code base. However, changes to TB seems to have quieted down now and QF has been able to catch up to TB's changes.... AND I am preparing to upgrade my Ubuntu Linux from 20.04 LTS to 24.04 LTS when the stable version is released in 2-3 months. So, it will soon be time to update everything.
Third, our environment: As I have mentioned before, our TB connects to IMAP. In the IMAP are many thousands of mail folders/boxes [now getting close to 20,000 folder in the IMAP], organized in hierarchical structures of mail folders. These folder structures run about 8 folder levels deep.
... when I use the keyboard QF commands to "go to" or "move mail to" a mail folder, the speed of QF/TB' presentation of the choices of mail folders to [go to | move into] depends upon the "common-ness" of the character that I first type when I am using the keyboard method.
... For example, if I want to "go to" the folder of client #12345, I type "12345". If I want to go to the folder of Soso Company, I type "soso". HOWEVER QF/TB stalls for a countable number of seconds (5-15 seconds) if that FIRST TYPED CHARACTER is a "1" or an "s". Those two particular characters take the longest because they are the most common in our folder names. In fact, typing "1" can result in TB completely freezing up (and then TB has to be killed from the command line, lock files have to be removed, etc., etc. -- very messy). Other characters take slightly less time, and some characters that are "rare" in the indexing, (such as "u, v, x, y, and z") are almost instantaneous (as it should be). The problem is related to the "common-ness" of the characters in the IMAP folder names.
... My understanding -- which may be wrong -- of the reason for the delay is that the searching delay depends upon the "rarity" or "common-ness" of the first one or two characters that are entered.... and that QF starts searching after [two ???] characters are entered. And then as each additional (one or two?) characters are entered, the result set is further narrowed down (all probably happening in the background, not visible to the user, unless the user is typing very slowly).
MY SUGGESTION: Assuming I am at least half-right about this situation, I would like to suggest an OPTION in the Pro version to require the user to do some sort of "submit search action" keystroke when the user has completed entering what they wish to enter in the search box. This should just be some sort of keystroke (or combo, such as CTRL or ALT + something). It would be the keyboard equivalent of clicking "start search" if one were using a dialog box that did searching.
... Thus normal behavior would continue as now. the user would type "12345". [In my case, I would wait about 15 seconds for the result to appear.]
... But with the option turned on, the user would type "12345[KEYSTROKE]". The search processes would not even start until the user has typed [KEYSTROKE]. The search would then operate only using the full typed string (in this example "12345"), presumably speeding up the search (with the assumption that TB is using some built-in indexing system of what it sees in the IMAP).
Such a feature would not only speed up my use of QF/TB, but it would also reduce the possibility of freezing up TB and having to kill and then clean up TB.
First, let me say that I "could not live without" QF Pro. It is excellent. I have multiple QF Pro licenses for the different seats/users in our office.
Second, let me explain that I am still using an older version of QF because I am still using an older version of TB... because I have not been willing to risk updating TB and then losing the mission-critical functions of QF because of the constant TB updating major changes to their code base. However, changes to TB seems to have quieted down now and QF has been able to catch up to TB's changes.... AND I am preparing to upgrade my Ubuntu Linux from 20.04 LTS to 24.04 LTS when the stable version is released in 2-3 months. So, it will soon be time to update everything.
Third, our environment: As I have mentioned before, our TB connects to IMAP. In the IMAP are many thousands of mail folders/boxes [now getting close to 20,000 folder in the IMAP], organized in hierarchical structures of mail folders. These folder structures run about 8 folder levels deep.
... when I use the keyboard QF commands to "go to" or "move mail to" a mail folder, the speed of QF/TB' presentation of the choices of mail folders to [go to | move into] depends upon the "common-ness" of the character that I first type when I am using the keyboard method.
... For example, if I want to "go to" the folder of client #12345, I type "12345". If I want to go to the folder of Soso Company, I type "soso". HOWEVER QF/TB stalls for a countable number of seconds (5-15 seconds) if that FIRST TYPED CHARACTER is a "1" or an "s". Those two particular characters take the longest because they are the most common in our folder names. In fact, typing "1" can result in TB completely freezing up (and then TB has to be killed from the command line, lock files have to be removed, etc., etc. -- very messy). Other characters take slightly less time, and some characters that are "rare" in the indexing, (such as "u, v, x, y, and z") are almost instantaneous (as it should be). The problem is related to the "common-ness" of the characters in the IMAP folder names.
... My understanding -- which may be wrong -- of the reason for the delay is that the searching delay depends upon the "rarity" or "common-ness" of the first one or two characters that are entered.... and that QF starts searching after [two ???] characters are entered. And then as each additional (one or two?) characters are entered, the result set is further narrowed down (all probably happening in the background, not visible to the user, unless the user is typing very slowly).
MY SUGGESTION: Assuming I am at least half-right about this situation, I would like to suggest an OPTION in the Pro version to require the user to do some sort of "submit search action" keystroke when the user has completed entering what they wish to enter in the search box. This should just be some sort of keystroke (or combo, such as CTRL or ALT + something). It would be the keyboard equivalent of clicking "start search" if one were using a dialog box that did searching.
... Thus normal behavior would continue as now. the user would type "12345". [In my case, I would wait about 15 seconds for the result to appear.]
... But with the option turned on, the user would type "12345[KEYSTROKE]". The search processes would not even start until the user has typed [KEYSTROKE]. The search would then operate only using the full typed string (in this example "12345"), presumably speeding up the search (with the assumption that TB is using some built-in indexing system of what it sees in the IMAP).
Such a feature would not only speed up my use of QF/TB, but it would also reduce the possibility of freezing up TB and having to kill and then clean up TB.