Float separate search

[Xyzzy]

[quote="teefan"]
Why you must be unpleasant for people who want to improve something? [/quote]

I don't see it as an improvement, really, really, really. More like adding confusion, which luckily has been removed.
A change or addition is not always an improvement.

As Leo have said, come out with scenarios that show that separate dialog is better IN MAJORITY OF SITUATIONS, not just when you have 3 monitors or "have an idea".
Just a couple of voices opposing from thousands of DO users rather confirms that removal of the window was OK.

Anyway, submit you request and wait.

My 2 cents, again.

[krkaem]

@teefan : if you switch to a second lister and want search results THERE, you have to open the find panel again anyway. Or do you think Opus should
know which lister was focused most recently to write the results there?
If not, then an option "automatically close find panel" would be helpful for you?!

[EDIT] - PS: i suppose the new "automatically shrink panel " option does not fit your needs

[Leo]

@teefan

(for example - one lister as source shows results when i search for ".txt" files, then I switch to another lister, search for ".jpg" files and that seems to be just more easy like opening another lister with find window, search for files, closing find panel, opening new window with find panel, searching for files etc.)

Krkaem asked a good question about how the window would be tied to the lister. Maybe some people would the Find window to stay with whichever lister opened it while others would want it to go with the Source (i.e. last active). Which is best isn't clear.

Also:

If you want to do multiple searches in different listers, I don't understand what's wrong with pushing Ctrl-F after changing to each lister. At least to me, that seems easier than dealing with multiple connected windows. Obviously it's about what we're all used to and personal preference, so I'm not saying I am right and you are wrong, but I am wondering if there is something I haven't understand that means Ctrl-F (or similar) doesn't work for you where a Find window would work better. For example, is the problem with Ctrl-F that your lister needs resizing to fit the panel in? (Ctrl-F could be changed to resize the window as well, or to ensure it has a minimum size, if that's the case. Would that help, in addition to the Find panel auto-shrinking/hiding?)

Do you actually want to see the results of two different Finds side-by-side that often? Or do you want to do two Finds and do both in advance, but only look at the results of one at a time? If it's the latter, would sending the results to tabs make more sense? You can do that already, but only by manually changing the collection name. We could make that automatically change the collection name the same as when doing two Finds in two separate windows if that would improve things.

@teefan

Why you must be unpleasant for people who want to improve something? This is forum where people discuss on various topics related to Directory Opus. If you want only positive feedbacks, then guestbook is more proper than forum. As I think, everyone here want to make Opus better and no one want to hear that he is troll.

If I'm being unpleasant, which is not intentional, it is because I am finding this thread so frustrating.

All I've done is ask for people to read what's been written and then, if not satisfied with how things are, explain what they want and why they want it, so that we can try to understand what everyone is asking for (which isn't a single, coherent request; it's lots of different, vague suggestions), and understand what problems each person has that they want to solve, and how we might go about solving them (either through changes to Opus or through explaining how to do things).

At the same time, people have to accept that not every idea is going to be implemented (the program would be a mess if we implemented every single suggestion anyone made), especially if nobody has made a good case for that idea. That doesn't mean we're ignoring our customers; there are lots of customers we have to consider and lots of potential work that can be done, and we cannot please everyone and do everything.

I'm not saying people can only give positive feedback; I'm saying we only want useful, constructive feedback.

You'll have to forgive me, also, for not being someone who frequently needs to do multiple side-by-side Find operations. While I do such things occasionally, it's not an every-day thing for me, so maybe I don't understand what the problems are and I need someone who does do lots of parallel Find operations to explain them to me.

[steje]

I am among those who want a separate "floating" search dialog... the reason is simple; in that I just do not like having so much of my lister (particularly when I'm in dual horizontal display mode) obscured by the find panel.

Turning the challenge to explain how the old way (or at least different than the current/new way) is better than what we have now around on itself - the only arguments I've ever seen for why the current way is supposedly better than the old is that it contains more useful actual "functionality" than the old tool, and that the old tool had legacy code defects that made it non-optimal to maintain. But those improvements in functionality have nothing to do with the central dislike some users have expressed for having the panel open in-lister. The blissfully ignorant perception of those who know nothing about whatever was code-deficient in the old find tool is most likely that any "functional" improvements in the find panel probably didn't necessitate a non-detachable in-lister panel implementation... but this is just a circular discussion back to the fact that the panel wasn't "new" in v10, that it's been there for YEARS, and was presumably already more agreeably implemented from a code perspective... and wasn't something that was about to be re-written to be "float-able" like the old tool.

For those of you still moaning the loss of the old detached find tool... please make note of the changes in the recent beta's:

@jon

Added 'Automatically shrink panel' option to the Find panel. The Find function now also displays a busy indicator in the status bar, which makes it easier to abort the search if the panel is shrunk.

@jon

If a Lister opens showing the find/sync/dupe panel, the panel is given focus rather than the file display

With these changes, I think the main 'burden' of using a separate layout from a workflow standpoint has been addressed... namely, that you had to manually CLICK into the name matching field in order to enter your search criteria before executing your search. Well, FIXED - thank you jon!!! Additionally, if you were the type of user who used to output the find results to the Find Window itself, the "Automatically shrink find panel option" is still useful in a separate Find Layout window (though it's probably more for making it more convenient to use the panel in-lister) because now you'll see MORE results in that separate detached lister than you could have seen in the old find tool window - since this option eliminates the find dialog fields from the "window" making more room for viewing more files...

Besides these much appreciated tweaks - I think the challenge from Leo/GPSoft then becomes stating details of what else people feel is important to change and why...

Along those lines - I had sent in very detailed suggestions to GPSoft covering ALL of the ways I think that the use of a dedicated "Find Layout" such as is described throughout this thread... can be enhanced so that it is not only completely functionally equivalent in every way to how the old find tool could be used - but reasons why basing it on the existing "Layout" system makes it better than anything we have or have had. But to Leo's point, there haven't been very many detailed comments here from many users explaining what they want and why it would be better. I can tell you that what I suggested includes a hefty amount of coding work for not a lot of tangible benefit - just to address some otherwise trivial deficiencies that using a separate layout today still has in comparison to the older, slimmer find tool dialog... mainly around how much bulkier a lister layout is (with all the normal toolbars turned on, etc) than just the UI stuff needed for the find fields...

I think, for the majority of users who have expressed dislike for the current in-lister panel method we can pretty safely skip past the fundamental reasons why we don't like having our file displays displaced by the panel, and play ball with what Leo's asking for. Namely - to provide details on what ELSE (since the changes mentioned above have been made) you find disagreeable about using a separate find layout to give you the desired "floating" search dialog you miss. From where we are now, I think the remaining potential "issues" boil down to simply these:

[ul][li]relative visual "bulk" of your normal toolbars when present in a separate find layout - that might look ugly or distracting when used with a minimally sized lister...[/li]
[li]whatever output method you used to use in the old find tools "show results in" drop down[/li][/ul]

Personally, I was never that happy with how the raw FIND command interacted with the old find tool. I recall it not populating the find dialog with options that could be used with the raw command. I stopped trying a long time ago - but now with the old tool having been eliminated - I'd like to see tighter integration with the Find Panel and the raw find command (if not already the case - but implemented in such a way that I could still use the raw command prior to calling up a separate find layout) such that any options used with the command are sure to pre-populate the resulting equivalent fields in the panel. It's not really directly related to replacing the old find tool - but with the changes already made - the only thing I strongly feel is still deficient in the separate Find Layout idea is the bulk of the lister; but is something I think would require a great deal of code change. I'm hopeful that we'll see those changes as the "idea" I've expressed on how to do it would provide other benefit outside of just the "floating search" use-case... but I'd "deal with it" the way it is in favor of more "functional" improvements in how we could use the separate find layout via raw commands - which to me, would make the "new" way unquestionably better than the old way.

ALTERNATIVELY: for those who still won't like the "layout" idea... if it is indeed because the lister is still too bulky compared to the old find tool - what don't you like about using the SMALLEST possible floating search dialog using a RAW command like I posted earlier:

Find NAME {RS|Specify search string...|{clip}} IN {s} RECURSE SHOWRESULTS=tab CLEAR QUIET

The only issue I've had with it - is that there seems to be a strange lag in terms of the operation running and completing vs when results from the operation seem to appear in the lister. On "big" searches - I often see results continue to appear AFTER the operation has seemingly finished (at least the 'abort' message in the display has disappeared, and the main bit of hard drive thrashing seems to have ceased). Haven't submitted an issue for it yet - but will.

</end_another_novella>

[BeeTeeEss]

Hello Leo...

My suggestion is less ambitious than Steje's, and accordingly, should presumably be less demanding to implement.

I believe the only real dissatisfaction with the Find Panel is the way it clobbers the user's working layout, which is not only inconvenient, but is also often not suited to the task being asked of it.

So my suggestion is that GPSoft should provide a (hidden) Find layout complete with the Find Panel, which would be invoked by a command such as:Prefs LAYOUT="Find"
As there is already a hidden Synchronize layout invoked by the command Go CURRENT DUALPATH={destpath} LAYOUT=Synchronize which was supplied by GPSoft as long ago as I can remember using DOpus, then the code to do something similar for the Find Panel presumably already exists.

You suggest that it is impossible to anticipate the multitude of possible options your users may want, but this did not stop the creation of the Synchronize layout which has satisifed my needs admirably. Notwithstanding that, however, once GPSoft has done the basic task, it becomes a trivial exercise for those who want something different, to modify the standard offering to meet their needs.

Please, Leo, don't suggest that it is just a noisy minority , or worse still trolls, making waves over this issue. Rather it is a group of DOpus users, who have, in the DOpus tradition, brought their concern to GPSoft's attention in the hope that, as has been the norm in the past, GPSoft would respond positively.

[Leo]

Bernard, I still don't understand why it would be useful for Opus to have a default hidden Find layout when:

[ul][li]You can already create your own Find layout.[/li]
[li]You'd probably want to save over the default Find layout with your own. (So having one created for you by default doesn't give you much.)[/li]
[li]The Find layout would not be used by default, so you'd have to configure things anyway. (Since you're configuring things, which you can already do, what is actually gained?)[/li][/ul]

You suggest that it is impossible to anticipate the multitude of possible options your users may want, but this did not stop the creation of the Synchronize layout which has satisifed my needs admirably.

I'm not sure the special Syncronize layout still makes sense today, except to maintain compatibility with old toolbars. (Note that it is not used by the default configuration.)

The reason that special/hidden layout existed in the past was so you could have a Sync layout without it cluttering up your main list of layouts. This is a potential source of confusion because a layout called "Synchronize" (or whatever it's called) is special, yet hidden and not something you'd know existed from just looking at the layout list. If someone tries to create a layout with the same name they may run into problems. The fewer special/reserved layout names the better.

These days, you can mark any layout you wish as hidden to prevent it from appearing in any layout menus. So the need for special/hidden layouts is no longer really there.

Please, Leo, don't suggest that it is just a noisy minority , or worse still trolls, making waves over this issue.

Argh!

Everyone, please stop over-reacting to what I said.

I said Plunder was acting like a troll in one post. (And in a PM he seemed to agree and asked for the message to be deleted, but by then it would've looked weird to delete it when there were replies & references to it, and lots of people had read it.) I didn't say everyone asking for the change was a troll. I didn't even say Plunder was a troll. All I said/meant was that posting something that added nothing to the discussion, and about a discussion he didn't actually care about the outcome of, was doing nothing but pour fuel on the fire.

And it is a minority. You can count the number of people asking for this on your fingers (and even those people aren't all asking for the same thing!). That doesn't mean we won't listen and take on-board the ideas that we think will work. (We've already implemented several suggestions that have come up in this thread, and I keep asking for more ideas -- backed up with information on how and why they'd be useful so we can understand them properly. If we were ignoring the whole thing then I'd just stop reading the thread entirely.) It does mean, however, that everyone in this thread has to accept that we are not writing Opus for them personally and we may choose to do things differently to what they suggest.