Any chance of having "Dynamic Folders"

In the now long defunct Journlr program, which I used as my research tool alongside Scrivener, it was possible to have dynamic folders that would automatically scoop up documents based on some content be it free text, keywords, or tags. I’d love to see the same feature within Scrivener.

Just open your eyes.

User Manual 10.2: “Using Collections”.

Except that Collections are not automatic. To quote from 10.2.4 “Given their dynamic nature, the contents of a saved search list cannot be added …”. These are not the same as general dynamic folders. A closer anology is SQL’s “CREATE TRIGGER” statement with either UPDATE or INSERT clauses. The SQLite documentation has a better description.

They “cannot be added to, …” – because they’re automatic. I use them all the time (primarily with keywords), and you tell me it’s impossible. :man_shrugging:t2:

1 Like

There is an interesting hybrid approach, that I think you may be describing, between the two types of Collection that Scrivener offers. The choice you have now is between a fully managed list, which is analogous to a folder full of aliases in Finder, and a something that is analogous to a Smart Folder in the same. You either have full control or no control (save for tweaking the search parameters).

Scrivener, as with Finder, has never offered a hybrid approach that blends those two ideas, save for its Bookmarks pane in the inspector. Now that isn’t a search parameter driven tool, rather it is driven by back-links. You link to something, and a back-link Bookmark entry is added its list so you can see what refers to it—while at the same time being able to manually delete that back-link if you don’t want it, or add your own references, and organise them as you see fit with drag and drop.

There is a lot of value in a collector system that uses that hybrid approach, but at the moment there is no framework for such a thing in Scrivener’s architecture.

It’s been so many years since I’ve used Journlr that I don’t really recall the specifics of how that worked. The closest comparison I have is how Boswell worked, where its collections analogue (the “Notebook”) would gather items into it when you archived material into the database from the working area, but the result of that action was to add items to a list you had full control over. You could remove false-positives, rearrange them and add your own that the filters didn’t catch.

With Scrivener that concept is a little more difficult to execute because of how anything could conceivably match a filter at any point. There is no “archive” mechanism like there was in Boswell, where once something was archived its content never changed, or SQL trigger on insert, where the data arrives into the system fully intact rather than starting as a completely empty row that you then start writing data into and assigning metadata. In short, all reasons why I am curious as to how Journlr worked, as I recall it being more like Scrivener in that everything was dynamic, free to change at any point in time. If you accidentally typed in the name of the wrong character into a scene, would it end up in that character’s collection list even if you deleted it seconds later? Problems like that make me wonder how suitable that model could be in a program like Scrivener.

At the moment, the closest thing to it is through a combination of tools:

  • You start with a search collection, and let it build a preliminary list, and then use the Navigate ▸ Collections ▸ Convert to Standard Collection menu command. This strips the search parameter from it and turns it into a list you have full control over.
  • Where that approach stumbles is of course in gathering future additions to the list in an automatic fashion. So to that end the second tool you have available is the capability of merging dynamic results into a static list. Instead of actually converting the collection to standard, as described above, you select the entire contents of the search collection and click the + button to create a new standard collection from that selected list. The result is identical to the above, save you now have two collections: one working as an automatic collector, and the other storing a permanent arranged view of the same. To update the standard list with new acquisitions, you go into the search collection, select all, and drag them into the static collection’s tab. Any duplicates will be ignored and their order as you arranged them maintained, meaning only “new” acquisitions are appended to the bottom of the list (“new” here meaning anything not currently in the static list, which is different from being actually new to both lists, a distinction I’ll get into below).

In other words, you get a hybrid model by combining the two existing models with a very small amount of manual labour. And I think, if such a model ever were to make its way into Scrivener, it would have to follow a similar but more streamlined approach.

Consider: a Navigate ▸ Collections ▸ Freeze Search Results command that essentially just turns off the automatic search, and while in that state allows you the same freedom of control you have over a standard collection. There would be a button added to such a collection’s header bar that would run the search once, appending and new items to the list at the bottom.

Such an idea is still rife with problems though, like how to handle not appending things you’ve removed in the past that still match the latent search criteria (what I refer to above as “new” items in scare quotes). Essentially such a feature would have to keep track of the changes you’ve made so as to preserve them. It could get messy internally—that’s a of background code where things can go wrong. If such things could be neatly solved internally, then you wouldn’t need a “semi-automatic” approach as I describe, and could fully automate a hybrid collection.

So to circle back to the beginning, it is an interesting thing to think about, but for now I would settle on developing a workflow using the existing tools. It’s not a bad approach—I’ve used it myself now and then.

1 Like

Your answer exemplifies a problem with the user manual. It is at best obfuscatory and more generally — including this instance — incomprehensible. As I have commented in these fora many times the manual is useless!

I’m afraid I can’t change that (just a fellow user).

In other words dynamic folders — however one thinks of them as working in Finder, Journlr, or Boswell — do not exist in Scrivener.

They exist. “Saved Search Result Collections” (10.2.4). With one caveat, and that is:

“The contents of a saved search are dynamic, but won’t change constantly while you are looking at it. You can refresh the tab by opening the Project Search field and pressing the Return key.”

(In other words: You have to trigger the refresh, but the results change dynamically based on your search criteria.)

3 Likes

But [having to} trigger[ing] a refresh is not automatic. Therefore my wishlist request both stands and is valid.

Good luck with that.

1 Like

Could youj be any more rude! Ad homineum argument at the stqrt 'juist open your eyes" and now this!!!

Wait a minute. You said: “I’d love to see”, to which I replied: “open your eyes” – which leads you to seeing what you’d love to see. Because it’s 99 percent already there. The other 1 percent is a minor annoyance (you having to pull the trigger). I even wished you good luck with that.

In short: Yes, I can. But I won’t.

2 Likes

I’m afraid there isn’t much more to discuss at this point, given the conversation has turned into a back and forth. I’m closing the topic, as evidently reepicheep doesn’t want feedback on the concept they brought up, and would prefer it just stand as an isolated feature request. That is fine, but it means we don’t need any further discussion. :slight_smile:

5 Likes