How do I create a new smart folder?
You don’t, exactly. But each tag you have shows up as a possible filter in the source list, and if you select more than one you can do an AND search on those tags.
EDIT: I meant OR, of course. Stupid typo. Unison, not intersection.
Actually, selecting multiple sources is like an OR. The ability to create new smart folders is on the to-do list.
Thanks, can’t wait for smart folders. I’m trying to replace my mail archive and SOHO notes all in one fell swoop, and I currently use a bunch of smart folders to organize my mail.
How do the tags work as filters? I have tagged messages, but don’t see a way to filter by tags.
Tag folders filter in the sense that they only show the records with that tag. It’s not currently possible to filter by tag using the search box.
I don’t understand “Tag Folder”. I have a folder full of tag words in the left column, but when I select them there are no messages/items displayed.
That must be because you haven’t actually assigned any tags yet. To do so, just drag an item(s) to any one of those words, or select the item(s) and then in the ‘tags’ palette check off the ones you want to apply, or write what you like in the ‘tags’ field of the Inspector.
Also, EagleFiler 1.0.2 doesn’t show e-mail messages in the tag sources, just files. This limitation will be lifted in the next version.
I started with email import and am building my file from there, so that explains it.
Which is EagleFiler 1.1.
As to the upcoming smart folders: as per the normal folder structure of EF being a representation of what is in the finder, will the smart folders (a) be represented in the finder as Finder smart folders, or will they (b) be smart folders in EF, and normal folders in the Finder, or © neither (i.e. only smart folders in EF, nothing in the Finder)?
I would strongly prefer (b). For me, one of the great benefits of tagging + smart folders (based on those tags) is “backup”, if they are represented intelligently in a way that Finder can read them. Why? If EF ever disappears, or I have to send my folder hierarchy to a non-EF using computer, the fact that I have one file tagged by more than one tag, and thus in more than one folder, is the type of taking advantage of computers without being limited by the metaphor of real folders (where a single file can obviously not be in more than one folder at once).
I realize this might cause a proliferation of files created in the Finder, while if it was limited to what is in EF, the other files might just be aliases. Perhaps a user-setting, in which the user determines “multiple tags create multiple files”, or “multiple tags create aliases” could be instituted?
To be honest, even if only aliases were created in the numerous subfolders, that would be better than nothing. Again, the reason I think this is important, is because – to me – the strength of EF is that it is one of the few programs to actually store itself in the normal Finder folder system. And I’d like the upcoming smart folders to capitalize on that, without diminishing the strengths of tagging and smart folders as well.
It will probably be ©. A smart folder is just a set of saved search criteria–they don’t actually hold anything–so it doesn’t make sense to represent them as regular folders in the Finder. And since Finder smart folders won’t be able to handle what the EagleFiler ones can (the Finder knows nothing of tags, notes, or messages), it won’t be (a).
If necessary, you can select the records in a tag source (or smart folder) and export them to a regular folder in the Finder. Or, it should be possible to use AppleScript to create folders of aliases. But I don’t think it makes sense for EagleFiler to constantly maintain lots of folders of aliases to your files; that would be pretty slow.
Glad you qualified that with “to me”.
I don’t care (much) what EF’s backend storage is as long as it’s reliable and I’m able to intelligently export from it to the traditional filesystem in a useful way. Any EF-specific metadata and structure would require a some external representation unless it’s unnecessary or discarded. EF seems designed to minimize (meta)data being held hostage by it; obviously a good thing. I still have 25 days to decide if that has a side effect of imposing limitations on capabilities I’ll want from it, sooner or later.
Some people want/need the ability to manage EF (meta)data outside the app to differing degrees. I definitely see reasons of value in doing that, though I’m not sure the risks of confusing EF in the process so I’d typically prefer its storage hierarchy be off limits to external access unless there’s no other choice or I’m certain of no negative consequences. Whew.
More simply and accurately, I’d normally treat EF storage as read-only outside of EF. Much like iTunes and iPhoto storage, actually. I don’t know (yet) what amount of external tinkering can be done behind EF’s back without corrupting its library whereas iTunes/iPhoto libraries are quite sensitive to that.
Just sharing a bit of my perspective without any key point to make.
Well, in a perfect world, the metadata associated with ANY file in Mac OS X would be flexible, such that a user could add his/her own types of metadata (as Tinderbox does so brilliantly). You can kind of do this through programs such as SpotMeta and others, but the lack of integratin with other software is problematic.
Regarding the backend being a normal file system, if you ever want to link to something in your databsae from another program, you’ll quickly realize the benefit…this is a gripe I have with DEVONthink (though that’s slated to change). And while, yes, you CAN get your stuff out of things like, say, Journler, it’s a lot more work than what EF gives us. But, yes, this is a relative benefit, relative to a user’s work flow…and I will readily admit i quite like it!
I couldn’t agree more. Without ubiquitous metadata support (whatever that eventually means/is; I’m optimistic it’s emerging) we’re limited to choosing apps with different and often non-interoperable implementations. File formats excluded, hierarchical organization becomes their lowest common denominator of interoperability or integration, enforced by two dimensional file/folder filesystems. (cf. other related thoughts)
Funny you mentioned DEVONthink and Journler because I was thinking of them both while composing that other post in a way much like you described.
I’ve never used Tinderbox though some of what I know about it has intrigued me.
Do: edit the contents, label, and Spotlight comments of files in the library.
Do not: move files or folders around or edit the contents of a mailbox file.
Gee, those rules are easy and obvious enough. Thanks, Michael.
Looking forward to Smart Folders!
There are about two or three things that I really wish EagleFiler had. One of them is Smart Folders. (I know it’s on the list, but I figure positive encouragement is always warranted! [grin])
EagleFiler 1.4 adds support for creating your own smart folders.