C-Command Software Forum

groups, bundles, packages, tags, folders

hello –

thanks for the very nice program. i have a feature suggestion. the short version is: it would be nice if eaglefiler directly supported os x bundles (“packages” in the developer docs) as taggable documents, and could view / modify / index the constituents of those bundles.

the long version :

often times, one has multiple physical documents which are logically a single entity. examples of this include

  • PDF paper + bibliographic / bibtex citation (BibDesk)
  • bookmark + (multiple) HTML / webarchive snapshots of the same web page
  • (small) source code repository tree (e.g. one or more .h and associated .C files)
  • multiple chapters / different formats of an electronic book
  • skim PDF + notes bundles
  • application bundles

i’m sure people can think of more examples.

some of these are already directly supported by EagleFiler (skim bundles, for example.) some are not. right now there are a two different ways to handle the non-supported cases :

1 - create a folder for each entity
2 - create a tag for each entity

the problem with folders is that folders are not records in eaglefiler – they can’t be tagged and they can’t be indexed (they don’t show up in searches.) tags are somewhat better in that tags can have tags (hierarchical tags) but they also are not first class records. tags don’t match the concept of entity very well either.

as i’m sure you’re aware, in os x there is a standard solution for this : “bundles” or “packages”, which are just specially-marked folders that get treated like a single entity. they are easy to create (just make a folder and set the bundle bit) and in the finder they appear to be a single file. i’ve tried putting a bunch of pdfs into a single folder and setting the bundle bit, and importing that into eaglefiler. it appears as a single taggable record, which is great, however the internal pdfs do not get indexed (nor can you browse or preview them.)

i propose the following feature : in the absence of a more specialized importer (e.g. for skim documents), eaglefiler gets a new, “generic” bundle importer. the generic bundle importer will recursively index the contents of the bundle and add those keywords to the top-level bundle. there is a viewer for the bundle which allows for the contents of the bundle (which are just a folder hierarchy) to be browsed, and the individual files viewed.

there are additional features which may or may not be added. one might want to be able to separately reference and index the constituent documents. in the first proposal, as far as the indexer is concerned, the bundle is one big document. not sure what the right thing here is. also, it might be nice to be able to modify the bundle, to move things around, delete, add or take things in and out of the bundle. i haven’t thought in depth if there are any issues with nested bundles, though.

another option is, instead of a generic bundle importer, to create a special eaglefiler-bundle-type. the same features could be supported, and you could have more control over the format, and possible add Finder support (quick view.)

i think this is a relatively simple suggestion, which i think could be a powerful tool. i of course don’t know the implementation cost but i imagine it should not be terribly difficult.

this is just a suggestion and i’m curious about people’s thoughts on it.

best regards

i forgot to mention : another alternative would be to simply allow folders to be first-class records. let them be tagged, and indexed according to their contents.

b

To me, “supporting” packages means recognizing when a folder is a package and then treating it as an indivisible unit (i.e. like a file) rather than like a folder. EagleFiler does this. You seem to be suggesting the opposite treatment, something along the lines of the Finder’s “Show Package Contents” feature.

I’ve never seen Web archive or source code bundles in the wild, and I don’t imagine that people would want to view the contents of Skim or application bundles in EagleFiler. Is this mostly about folders that you yourself are marking as bundles?

That’s not correct. Folders in EagleFiler are treated the same as other records. They can be tagged, searched for, have notes, etc.

It seems like this would be undesirable for the common case of a packaged document format that EagleFiler does not have a specialized viewer for (e.g. Pages or OmniOutliner). Most people will want these treated as single entities.

This sounds complex to me. And it’s not really clear to me what you’re trying to accomplish. Could you step back for a moment and give me the big picture? Where are the bundles/packages in question coming from? Which applications are viewing and editing them?

michael –

thanks for the prompt reply. first off, apologies for not seeing i could label folders. i was looking at the view where the folder is selected on the left pane, and nothing is selected on the right, and saw that the tag menu item was empty, and nothing in the right-click menu. (perhaps there could be a right-click menu item “tag folder” on folders in the left pane.)

i agree with you : if there is a special viewer for a package type, like skim, use it, otherwise present it as an opaque unit. i originally suggested having a generic browser for all unknown package types, which you point out is a bad idea. however, i proposed as an alternative to have a “special eaglefiler bundle” type, for the express purpose of keeping related documents tightly bound together; more on this below.

yes, i’ve never seen bundles much in the wild either, and this suggestion is all about making my own logical groupings. to clarify things, here’s a sample scenario :

suppose i have 25 pdfs for the chapters of a book. i put all the pdfs along with a bibtex plain text file into a folder “jon doe, 25 things i love about eaglefiler”. i label it with the labels “good” and “science.” later i forget about the book but remember a discussion about X, which i search for. X is found in the chapter 7 pdf. i use the “reveal in container” function to find the book folder, and then clear the search box to find the other chapters and bibtex. later, i’m looking for good reads, so search for the “good” label, and i find the folder. i browse inside the folder to find the chapters and other content.

“problems” (i’m using quotes to indicate i understand these are debatable) :

  1. the folder does not appear in the search for X – i have to know to navigate to it via “reveal in container” + clear search box to find the other items.

  2. the tags applied to the folder don’t get applied to the pieces. this is less of a problem because it is simple to navigate to the pieces once you’ve found the folder.

the tag alternative : i create a tag “john doe, 25 things i love about eaglefiler”, which is contained in the tag “science.” i tag each of the 25 pdfs and bibtex entry with this label, and also “good”. when I search for X and find chapter 7, i see the “john doe…” tag and use it to find the other chapters / bibtex. each piece shows up in a search for the “good” tag as well.

“problems”

  1. i have to use tags to indicate “logical records” rather than classes. these tags probably have really long names if i’m using them to identify things like academic papers. (i tend to think tags are things like “funny” or “research”.)

  2. tags are even looser than folders : in a search, items from the same entity might be visually very far apart. you might have a lot of chapter 3.pdfs.

  3. i have to separately tag every constituent when i want to tag (except for ancestor tags, but you can only have one line of those.)

the package alternative : i create a folder called “john doe, 25 things i love about eaglefiler”, put all the stuff in it, and somehow let eaglefiler know it is an “eaglefiler document bundle.” i label it “science” and “good”. when i search for X, i find the package. when i find things labeled “good”, i find the package. when i view it, i get a listing of the chapters / bibtex, perhaps with chapter 7 highlighted as matching the search, and i can click and view each of the individual files separately.

“problems”

  1. implementation cost : new special bundle type, with indexer, browser, etc.

  2. they are easy to view in eaglefiler, but the bundles are opaque to the finder, unless you add quickview support for them or something.

i’m also not clear how packages fit in conceptually with the related concepts of “folder” and “container” (e.g. mbox.)

so, taking a step back, as you requested, it seems i can do everything i want without a new eaglefiler bundle type, but it just might be slightly less convenient, UI-wise.

i wish i could experiment more with my (large and unwieldy) pdf library but the cost of getting things properly filed is pretty high.

so i’m withdrawing my feature request, but if anyone has any ideas on how this kind of usage might work better, i’d appreciate it.

i do have a few minor suggestions:

  • a preference which makes double-clicking on containers not open a new window (e.g. double-click for “contents in record”.)

  • a command “open containing record” which is exactly like “reveal in container” but empties the search box might be nice.

  • the commands “view enclosing record”, “reveal in container”, and “contents of record” all make sense but i find the names a bit confusing. especially “view enclosing record,” which can show an empty list if the search box is non-empty, which is often the case when i use the command (e.g. search, find an item, view enclosing record to go up.) it seems to me either a folder should show up if the anything inside the folder matches, or else these commands might want to clear the search box (and be called something like “up level”, “open containing folder”, and “browse” or “open”.)

all of this is just nitpicking on what seems like a really great product!

best regards

I can see how being able to mark a folder as a bundle would help here, but at the same time I think there are deeper issues about information management/storage involved. The bundle idea is a partial solution from a particular angle, but I wonder whether there’s a better way to tackle this. Anyway, thanks for the discussion, and I will think on this some more.

This will be possible in EagleFiler 1.5.

Have you tried the ClearSearchWhenChangingSources esoteric preference?

eager to see what you come up with. devonthink has a rather unusual tags = folders thing which seems interesting but is also kind of strange. together has strange one-level hierarchies in tags and grouping. so there’s at least a few different approaches here. in the meantime i’m just going to go with folders for now.

great!

no i had not noticed that option. thanks! i’m going to experiment with leaving things as-is, in case i get used to it – but i’ll keep it in mind if i decide the other way works better for me.

best regards