Here are a few examples of instances where I have had to bypass the collection module, by manual access to the database or otherwise:
* It is impossible to search for an exact match to a string. If, for example, I want to search for an image with the exact title "Water", I cannot exclude images titled "Desert with no water". * The tagging module is case-sensitive in its treatment of tags, but the collect module always ignores case. Thus, for example, if I have two tags named "Water" and "WATER", the module cannot be made to distinguish between them. More than once, when I have made a typo and accidentally created a tag such as "WAter", I have had to go into the database to re-tag images. * The current "list of rules" collection structure makes it impossible to formulate some fairly reasonable classes of queries, such as "A but not (B and C)". Also, even if most users do not need more powerful search functionality, one could still make a case for providing it in the API so that the users who do need it could access it through a Lua module without inconveniencing the rest. -- August Schwerdfeger aug...@schwerdfeger.name On Sat, Jan 20, 2018 at 7:19 PM, Mark Feit <mf...@notonthe.net> wrote: > On 1/16/18 3:53 AM, Heiko Bauke wrote: > >> >> Nevertheless, I am not fully convinced that darktable requires such a >> kind of feature. I am pretty sure that such complex search patterns emerge >> from time to time. But for typical use cases the current collection module >> is sufficient. >> > Typical use cases are limited by what the current collection module can > do. The only ways to find out if users are doing things outside of > darktable that could be done inside are to ask or be asked. In my own > case, the only thing I use the collection module for is pulling up whole > folders I've used before. Anything beyond that and I use home-brewed stuff > to paw through my library and then go back to DT and work by folder. > > Not that I think darktable needs to shoot for full feature parity with > Lightroom, but text search is pretty useful and has been available in that > product for almost a decade. > > ... darktable developers should evaluate xapian (https://xapian.org/). >> > Xapian wouldn't be a bad choice, either. I suggested Lucene because it's > very good at what it does, I have a lot of very positive experience with it > and it's in wide enough use that finding developers who understand it isn't > difficult. Most indexing APIs I've put together are a half-dozen calls or > less, so it really wouldn't matter what's backing it up if it's got the > right feature set. > > At any rate, my offer's on the table, it still stands for any indexer and > my feelings won't be hurt if it's ignored. > > --Mark > > > ____________________________________________________________ > _______________ > darktable developer mailing list > to unsubscribe send a mail to darktable-dev+unsubscribe@list > s.darktable.org > > ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
