Start with a search? Start with a button!

[admin]

I never really liked it when XY starts with a search (because it previously had been closed on a search tab).

What about this solution: Show the tab/list that would search with just a grey field, a little text, and a button "Search Now"? So you would always have a quick startup without burning the CPU while the GUI is not even fully loaded, and you would not lose the search specification and the search itself would be just a click away.

[Gandolf]

Never re-start a search when XY is opened is preferable to me.

[j_c_hallgren]

I never really liked it when XY starts with a search (because it previously had been closed on a search tab).

And...you're just saying this now, after how many yrs?

Anyway, not exactly sure how your proposal would look/work, but I would agree that not auto-starting search would be definitely preferable...as on some rare cases (when I do close XY), it started with a search and I'd had to make a quick reach for the ESC to stop it...but then used the INI tweak to block it from happening...though this proposal might mean I could handle it differently and have a bit of flexability.

And what would be the other option? I presume you'd have two choices "Search Now" and "Cancel" or similar, right? Thus allowing easy way to skip it.

[TheQwerty]

not exactly sure how your proposal would look/work, but I would agree that not auto-starting search would be definitely preferable

Pretty much exactly how I feel.

I've always enabled the INI tweak "NoFindOnStartup", so it of course sounds good to me, but yeah, not sure what you're thinking of showing on start instead.

[admin]

Okay, I show this message on a list that would search on startup.

Search blocked at startup
Press "Find Now" to run the search now.

Please help with the wording!

[Gandolf]

"Search disabled at startup" rather than blocked I think. Or, "Startup search disabled" might be shorter.

Obviously, if "NoFindOnStartup" is set, the message will not be displayed.

[Stefan]

Perhaps:

Code: Select all

Note: XYplorer was closed with an open search tab.
Do you want to do the search now again?
         [Yes]             [No]

[TheQwerty]

You know.. I almost think it would have made more sense to just leave this as it is, as Search Results caching isn't too far away (right?), and when that arrives you can just show the caching on start.

Why introduce a new GUI element that will probably be changed in the near future?

[admin]

You know.. I almost think it would have made more sense to just leave this as it is, as Search Results caching isn't too far away (right?), and when that arrives you can just show the caching on start.

Why introduce a new GUI element that will probably be changed in the near future?

Because it's necessary. It's the only way to handle it if you don't want the search to run and you don't want to "lose the search" (lose the specification of it). Cache is not 100% reliable (user might opt to no-cache) although it will generally reduce the necessity for the "block" message. BTW, it's not a new GUI element. It's same as what you see when you browse to an unavailable location, just with a different text/icon.

[admin]

Perhaps:

Code: Select all

Note: XYplorer was closed with an open search tab.
Do you want to do the search now again?
         [Yes]             [No]

Not bad, but what shall happen on "no"? Close the tab? Browse the current tree location? That's too vague.