Allow XnView DB SQL Queries in Search conditions

[danjcla]

XnView uses the easy to explore SQLite and has an awesome and easy to understand SQL Schema, but there isn't currently the capability to take advantage of what SQL is really good at from the XnView GUI itself: making any query possible, without having to add more code to your application for each new user request.

My experience so far is that the existing search GUI is really comprehensive in all areas except boolean logic - e.g. the stuff at http://en.wikiversity.org/wiki/Primary_ ... lean_logic - grouping with parenthesis, and, or, not, xor, etc.

But I'm sure there are many other searches people would like to do that are not too hard to do in SQL but are impossible with the current search function. Since the current search function is not, you know, an entire mostly-declarative programming language based on branches of algebra and calculus.

One way to do this would be to have "SQL Query" be a new condition type. Since the "Search..." UI expects each condition to take up a single line, there would have to be a drop-down list like with "Color label" that references SQL queries saved elsewhere in the UI, probably Settings.

This wouldn't be just for SQL knowledgeable users - it would allow users who know SQL to help those who don't by posting to the forums, telling the less technical users to just do [small set of easy steps] in the UI, and now you can easily do what you want in search from now on.

Or people could get the IT people to do it, their computer consultant, programmer friend, etc.

[danjcla]

More expansive and possibly faster to code way of implementing this: a condition "External script" that lets you choose a file. Perhaps with a text field next to it for optional arguments. The script returns /one/absolute/path/with/file/name.extension per line.

So this would allow the use of a little shell script that just does a sqlite3 query (or python, whatever), fulfilling the original idea.

But it could, of course, do absolutely anything. Make the set of returned photos be based on a comparison between anything in the database and any external source of information. Or even have side effects outside of the scope of XnView. For example, something that returned a set of photos, but also if the photo didn't have keyword "highest res available" start a google image search for each of those photos, downloaded any found images of higher resolution into the same folder as the original and with the same name with "-highres" appended, copied over in-file metadata from the old lower-res version to the new version, added the keyword "highest res available" to the "-highres" version, and then replaced the old version.

A lot of text editors have this kind of function - e.g. TextMate's "Filter Through Command...", I'm sure Sublime Edit, and of course vi and emacs since forever.