Raw search string to Everything
Moderators: white, Hacker, petermad, Stefan2
Hacker's idea is good, but I'd rather put the two checkboxes - the existing "Everything" and the proposed "Everything syntax" - next to eachother. Well, as I said, time for some dialog redesign .
Regards
Dalai
Regards
Dalai
#101164 Personal licence
Ryzen 5 2600, 16 GiB RAM, ASUS Prime X370-A, Win7 x64
Plugins: Services2, Startups, CertificateInfo, SignatureInfo, LineBreakInfo - Download-Mirror
Ryzen 5 2600, 16 GiB RAM, ASUS Prime X370-A, Win7 x64
Plugins: Services2, Startups, CertificateInfo, SignatureInfo, LineBreakInfo - Download-Mirror
Although I would have loved to see a solution that integrates the current search syntax and Everything search it might lead to a compromise solution which isn't a real step forward.
So my idea at this point would be to just create an alternative search dialog.
1) It would be really optimized for entering the Everything syntax. This means various search options that currently exist would not be transferred to the new dialog. Input helpers as in the MRT or auto-suggestion on typing would be welcome.
2) The new dialog would feature an easy global search option which is the default in Everything.
3) Everything that cannot be handled by Everything is still displayed in this new search dialog. This includes search in archives, plugin-based searches and the duplicate search. They would all be post-processed after executing the Everything search.
4) The search in text part is discussable. I would still prefer a seperate input field.
5) Maybe such a new dialog could also be a tab page in the existing dialog instead of a completely new dialog. The new tab could be shown/hidden using a global option. It would work like a pre-filter for everything else defined in the other dialogs.
What do you think? Other ideas?
So my idea at this point would be to just create an alternative search dialog.
1) It would be really optimized for entering the Everything syntax. This means various search options that currently exist would not be transferred to the new dialog. Input helpers as in the MRT or auto-suggestion on typing would be welcome.
2) The new dialog would feature an easy global search option which is the default in Everything.
3) Everything that cannot be handled by Everything is still displayed in this new search dialog. This includes search in archives, plugin-based searches and the duplicate search. They would all be post-processed after executing the Everything search.
4) The search in text part is discussable. I would still prefer a seperate input field.
5) Maybe such a new dialog could also be a tab page in the existing dialog instead of a completely new dialog. The new tab could be shown/hidden using a global option. It would work like a pre-filter for everything else defined in the other dialogs.
What do you think? Other ideas?
That is a great suggestion Lefteous !Lefteous wrote:Although I would have loved to see a solution that integrates the current search syntax and Everything search it might lead to a compromise solution which isn't a real step forward.
So my idea at this point would be to just create an alternative search dialog.
1) It would be really optimized for entering the Everything syntax. This means various search options that currently exist would not be transferred to the new dialog. Input helpers as in the MRT or auto-suggestion on typing would be welcome.
2) The new dialog would feature an easy global search option which is the default in Everything.
3) Everything that cannot be handled by Everything is still displayed in this new search dialog. This includes search in archives, plugin-based searches and the duplicate search. They would all be post-processed after executing the Everything search.
4) The search in text part is discussable. I would still prefer a seperate input field.
5) Maybe such a new dialog could also be a tab page in the existing dialog instead of a completely new dialog. The new tab could be shown/hidden using a global option. It would work like a pre-filter for everything else defined in the other dialogs.
What do you think? Other ideas?
I don't think it's a good idea to make a new dialog, but I like the idea to add a tab to the existing one.
If there would be two different dialogs, I can already see the questions coming up, why there's two dialogs and why they're different, and why people have to take the hassle to close one search dialog and open the other one to search with or without Everything, and so on. And what do you do when you want to add/integrate another search "engine" to TC, make another dialog?
Regards
Dalai
If there would be two different dialogs, I can already see the questions coming up, why there's two dialogs and why they're different, and why people have to take the hassle to close one search dialog and open the other one to search with or without Everything, and so on. And what do you do when you want to add/integrate another search "engine" to TC, make another dialog?
Regards
Dalai
#101164 Personal licence
Ryzen 5 2600, 16 GiB RAM, ASUS Prime X370-A, Win7 x64
Plugins: Services2, Startups, CertificateInfo, SignatureInfo, LineBreakInfo - Download-Mirror
Ryzen 5 2600, 16 GiB RAM, ASUS Prime X370-A, Win7 x64
Plugins: Services2, Startups, CertificateInfo, SignatureInfo, LineBreakInfo - Download-Mirror
2Dalai
I get your point. The main question is if there is actually a type of user who wants to search the classic way AND using the Everything syntax. You are of course right that a single solution would be better but this is really getting to complex using the current approach.If there would be two different dialogs, I can already see the questions coming up, why there's two dialogs and why they're different, and why people have to take the hassle to close one search dialog and open the other one to search with or without Everything, and so on.
My answer would be still to try to have a single syntax but it seems most users want a more distinct solution. That's why I thought: "When distinct, then really distrinct - not just a checkbox".And what do you do when you want to add/integrate another search "engine" to TC, make another dialog?
I also like it, but it also has its tradeoffs like the decision between creating redundancy on the Everything tab (e.g. use plugin search) and the need to go to another tab when incooperating TC search (only Everything stuff on Everything tab).I like the idea to add a tab to the existing one.
It all depends on the use case. Sometimes you want to search for specific file names only (using Everything), the next time you need to search in archives or any other stuff that Everything can't do but TC can. I certainly don't want to think about which dialog I have to call beforehand to do a search. IMO that would be unergonomic.Lefteous wrote:The main question is if there is actually a type of user who wants to search the classic way AND using the Everything syntax.
Well, the question is if it's necessary to make controls for every bit that Everything can do. I think about some selection mechanism that builds the string that will be sent to Everything. This string can still be edited manually, to allow for more complex syntax and new Everything features TC doesn't know about.[...] like the decision between creating redundancy on the Everything tab (e.g. use plugin search)
Well, you could add some mechanism that allows the user to call the search with the new tab selected, although this wouldn't eliminate the need to switch tabs completely.and the need to go to another tab when incooperating TC search (only Everything stuff on Everything tab).
Regards
Dalai
#101164 Personal licence
Ryzen 5 2600, 16 GiB RAM, ASUS Prime X370-A, Win7 x64
Plugins: Services2, Startups, CertificateInfo, SignatureInfo, LineBreakInfo - Download-Mirror
Ryzen 5 2600, 16 GiB RAM, ASUS Prime X370-A, Win7 x64
Plugins: Services2, Startups, CertificateInfo, SignatureInfo, LineBreakInfo - Download-Mirror
2Dalai
This is what I like about the extra dialog/redundant controls. It's the chance to see everything at one glance.
No, that's not my idea! It's just about the syntax. The basic idea is to filter as good as possible by entering an Everything syntax string and if necessary filter more using the TC capabilities (search in archive, plugin-based stuff, adv. duplic. search and so on). So if it's an extra dialog it would have to include everything that only TC can.It all depends on the use case. Sometimes you want to search for specific file names only (using Everything), the next time you need to search in archives or any other stuff that Everything can't do but TC can. I certainly don't want to think about which dialog I have to call beforehand to do a search. IMO that would be unergonomic.
My idea would be to have a simple text field like in Everything. It could be enhanced by type suggestions and some controls that promote the syntax similar to MRT.Well, the question is if it's necessary to make controls for every bit that Everything can do. I think about some selection mechanism that builds the string that will be sent to Everything. This string can still be edited manually, to allow for more complex syntax and new Everything features TC doesn't know about.
Exactly that's the point. The tab switch necessity has always been a pain in the ass. You just don't see all search settings. I drawed some mockups some time ago to improve this but wasn't happy with the results.Well, you could add some mechanism that allows the user to call the search with the new tab selected, although this wouldn't eliminate the need to switch tabs completely.
This is what I like about the extra dialog/redundant controls. It's the chance to see everything at one glance.
Are you sure about this when you intend to add the already existing search options:Lefteous wrote:This is what I like about the extra dialog/redundant controls. It's the chance to see everything at one glance.
Regards3) Everything that cannot be handled by Everything is still displayed in this new search dialog. This includes search in archives, plugin-based searches and the duplicate search.
Dalai
#101164 Personal licence
Ryzen 5 2600, 16 GiB RAM, ASUS Prime X370-A, Win7 x64
Plugins: Services2, Startups, CertificateInfo, SignatureInfo, LineBreakInfo - Download-Mirror
Ryzen 5 2600, 16 GiB RAM, ASUS Prime X370-A, Win7 x64
Plugins: Services2, Startups, CertificateInfo, SignatureInfo, LineBreakInfo - Download-Mirror
2Dalai
But no I'm not sure. I'm never sure before there is some kind of visualization.
It also includes removing everything that can be done in Everything and this is a lot. Beside the duplicate options the second tab doesn't have to be duplicated, the plugin tab is quite dynamic, ans so on.Are you sure about this when you intend to add the already existing search options:
But no I'm not sure. I'm never sure before there is some kind of visualization.
-
- Junior Member
- Posts: 45
- Joined: 2006-06-10, 21:41 UTC
- Location: Arizona
One of the strengths of Everything is its incremental search results (the results panel is updated as I type each character into the search field). In contrast, TC search doesn't execute until you press Enter. Since these are fundamentally different approaches, perhaps it would be better to have a separate dialog for Everything so it could display incremental results.
Rob
Rob
Not a bad idea but it may be a problem to display it in TCs window.Rob Weinstein wrote:One of the strengths of Everything is its incremental search results (the results panel is updated as I type each character into the search field). In contrast, TC search doesn't execute until you press Enter. Since these are fundamentally different approaches, perhaps it would be better to have a separate dialog for Everything so it could display incremental results.
Rob
IF I need incremental search I still can use Everything itself.
If you have a specific tab for everything, you could have a way to send the querry dynamically but this should be optional and not easy to match standard design.Rob Weinstein wrote:One of the strengths of Everything is its incremental search results (the results panel is updated as I type each character into the search field). In contrast, TC search doesn't execute until you press Enter. Since these are fundamentally different approaches, perhaps it would be better to have a separate dialog for Everything so it could display incremental results.
Rob
Or why not asking to everything developer to create a filesystem plugin that interact directly with standard Everything UI ?
nsp,
Roman
FSE-Fast Search Engine plugin?Or why not asking to everything developer to create a filesystem plugin that interact directly with standard Everything UI ?
Roman
Mal angenommen, du drückst Strg+F, wählst die FTP-Verbindung (mit gespeichertem Passwort), klickst aber nicht auf Verbinden, sondern fällst tot um.
This plugin allows you the full Everything syntax and was the best solution for TC 8.x and Everything integration.Hacker wrote:nsp,FSE-Fast Search Engine plugin?Or why not asking to everything developer to create a filesystem plugin that interact directly with standard Everything UI ?
Roman
For TC 9 it would no longer be necessary if we have the proposed Raw string to Everything.
Btw. the FSE plugin can't make incremental searches.