You still talk about views FOR filtering. I don't get that. Why make it so complicated?
You know full well I'm describing it that way because a "view" is a concept that currently exists in the program, is configurable in Theater View, and which I propose be adapted to provide more of a filtering capability.
What I'm saying is that a default set of filters first have to be in place that most of the users think would suffice.
As I said in my post, providing a limited set of filters only creates problems for no good reason. In a system that is completely configurable, a "default" is easily provided in the form of a default configuration—exactly as such things are done now. Look at
Tools - Options - Theater View. If there were nothing there (when it was in the "default" or "as shipped" state), you would see nothing in Theater View. And yet all that is there is fully configurable. I can't fathom why you would want that aspect of the program to be abandoned just because some filtering capability is being introduced.
Whether the current navigation method of narrowing a file selection is retained or replaced with filtering, a default set of categories for filtering would be provided. This would serve the dual purpose of providing a reasonably functional first time experience (that might work fine for many without modification), and an illustration of how the filtering can be adapted to one's personal circumstances and preferences. I would start by simply changing the categories that don't work to the equivalent custom categories in my database. You might change the default grouping for
Last Played from 30 to 120 days. We would all be able to remove what we don't need and add what we do. Everything I'm describing already exists in the current configuration facility. Why do I "still talk about views FOR filtering"? Because, in this regard, nothing has to change!!!
So, I think it's highly relevant. It's a bigger chance to implement something relatively easy at start, and then ask for improvements later on. To risk J River skipping the idea because all you use is custom fields, and that you demand complete customization, that's not good for anybody.
I trust the developers have no difficulty understanding something similar to what I've proposed fits best with what they've developed so far, involves the least effort to implement and would be readily understood by users. I'm not suggesting there shouldn't be further changes later on. But this is clearly a sensible starting point. Arbitrarily restricting filtering means more work for no good reason, and only creates problems for users. That's not good for anybody.
And in a feeble attempt to suggest this discussion has anything at all to do with the original subject of this thread...
The very same principles I'm advocating here apply to the Info Panel. The fields displayed in the panel need to be configurable. The easiest and most useful way to do so is make it fully configurable in exactly the same way views are. The configuration dialog should have a new section similar to "Columns to show" in
Customize View (in Standard View). Here, of course, it would be "Rows to show," and would allow any field or expression to be added and placed in any order. There would be two of these—one for the area under the thumbnail, and one for the panel itself. This is a rather simplistic form of customization, but it's simple, flexible and surely the easiest to implement. A sensible starting point that might be improved later on—by adding simple things like placing short fields side-by-side, to the more complex like facilitating custom layouts.