Support alternative image filters in popup

I've marked several other issues duplicate of this now, because this needs a well thought-out configuration and UI concept.

Feature requests mentioned so far:

• Filter images by taxonomy term via taxonomy autocomplete widget (this issue)
• Default popup filter to display all images
• Filter images by node title via node autocomplete widget
• Filter images by taxonomy term via taxonomy select list (built-in)
• Properly display hierarchical terms in taxonomy select list

I wonder if all of this wouldn't best be handled through views. I can't imagine a more powerful situation than being able to simply create my own image browser. Currently the user specifies which forms are to be equipped with img_assist. I imagine something like the profiles in the sIFR module, where a profile is created which applies to whichever forms; ideally the forms to use could be specified in a manner similar to the CAPTCHA module (which can add a link to forms to allow you to add a CAPTCHA to them.)

Simply using views and letting the user design their own selection criteria should buy you a solution to this issue (#220431: Support alternative image filters in popup) as well as #226826: Default to all images and #227051: Display image list per node or per gallery.

If you support passing arguments to the view, then it should be possible to easily use a single view to support filtering images by taxonomy terms or other node criteria. Supporting multiple user-configurable profiles as well (which themselves could pass arguments to views) lets you do it via select list.

The default view would simply provide an exposed taxonomy filter (thus automatically solving #80315: Show galleries with hierarchy) and would pick published nodes of type image. The view is a list of images which will need appropriate links. Then you launch into the second stage of img_assist as normal.

If the new image.module ends up as pure CCK in D7, this could also potentially allow the user to add other image node types, and then amend the view to include them as well (or only for certain types of nodes or whatever.)

This is probably a horrible amount of work but it's just my musing. It seems like it might be the only reasonable way to fulfill the broad range of potentially conflicting interface requests.

Marking as duplicate of #282184: Views integration, which is already implemented now. Using exposed filters, you can filter, sort, and do whatever you want to do.