Raw search string to Everything

Dalai · Post by *Dalai » 2016-06-22, 20:15 UTC

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

Lefteous · Post by *Lefteous » 2016-06-22, 22:31 UTC

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?

nsp · Post by *nsp » 2016-06-22, 23:18 UTC

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?

That is a great suggestion Lefteous !

Dalai · Post by *Dalai » 2016-06-23, 00:43 UTC

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

Lefteous · Post by *Lefteous » 2016-06-23, 08:26 UTC

2Dalai

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.

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.

And what do you do when you want to add/integrate another search "engine" to TC, make another dialog?

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".

I like the idea to add a tab to the existing one.

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).

Ovg · Post by *Ovg » 2016-06-23, 08:42 UTC

IMHO new tab only for Everything - good solution.

Dalai · Post by *Dalai » 2016-06-23, 12:26 UTC

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.

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.

[...] like the decision between creating redundancy on the Everything tab (e.g. use plugin search)

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.

and the need to go to another tab when incooperating TC search (only Everything stuff on Everything tab).

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.

Regards
Dalai

Lefteous · Post by *Lefteous » 2016-06-23, 13:20 UTC

2Dalai

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.

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.

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.

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, 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.

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.
This is what I like about the extra dialog/redundant controls. It's the chance to see everything at one glance.

Dalai · Post by *Dalai » 2016-06-23, 13:47 UTC

Lefteous wrote: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:

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.

Regards
Dalai

Lefteous · Post by *Lefteous » 2016-06-23, 14:14 UTC

2Dalai

Are you sure about this when you intend to add the already existing search options:

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.
But no I'm not sure. I'm never sure before there is some kind of visualization.

Rob Weinstein · Post by *Rob Weinstein » 2016-06-24, 14:33 UTC

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

Horst.Epp · Post by *Horst.Epp » 2016-06-24, 15:15 UTC

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

Not a bad idea but it may be a problem to display it in TCs window.
IF I need incremental search I still can use Everything itself.

nsp · Post by *nsp » 2016-06-24, 16:21 UTC

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 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.

Or why not asking to everything developer to create a filesystem plugin that interact directly with standard Everything UI ?

Post by *Hacker » 2016-06-24, 21:41 UTC

nsp,

Or why not asking to everything developer to create a filesystem plugin that interact directly with standard Everything UI ?

FSE-Fast Search Engine plugin?

Roman

Horst.Epp · Post by *Horst.Epp » 2016-06-25, 08:19 UTC

Hacker wrote:nsp,
Or why not asking to everything developer to create a filesystem plugin that interact directly with standard Everything UI ?
FSE-Fast Search Engine plugin?

Roman

This plugin allows you the full Everything syntax and was the best solution for TC 8.x and Everything integration.
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.