This may have already been requested but I didn’t see it in a search. One of the things I would like to do with EagleFiler (besides storing and archieving files) is project management. Now that EagleFiler can keep track of any file, it seems to be a natural application for grouping all those files that are tied to a specific project. However, I may have a single spreadsheet that is used by more than one project. It seems the use of aliases would be a perfect solution to this problem of having the same library file appear in several spots within the directory.
EagleFiler 1.1 will let you import alias files, but it will treat them as opaque documents whose contents it doesn’t know how to read. (Of course, you can double-click on the alias to open the original file.) I would like to add true support for aliases/links in a future version.
Are you saying that you want to have aliases within a single EagleFiler library so that the same file can be in multiple folders? If so, you can do something similar today by using tags instead of folders. Or are you saying that you want the same file to be part of two EagleFiler libraries?
Are you saying that you want to have aliases within a single EagleFiler library so that the same file can be in multiple folders?
If so, you can do something similar today by using tags instead of folders.
I see from an earlier post that smart folders are on the agenda. If so, that would meet my needs
Also hoping for alias
It would also be helpful for me if I was able to add files to eaglefiler but have eaglefiler only copy an alias of the file into its library, and to leave the original file in its current finder location. This is especially helpful if there was a way to do this for whole folders, and as you added or subtracted files from those folders in finder eaglefiler would also add/remove files. The only software I have seen that does a decent job of this is journalx. But eaglefiler could do a better job especially with the ability to retrain and edit finder comments.
I am looking at this primarily for needs associated with managing a large number of related files for projects.
This is something that I’m considering for a future version.
This will probably not happen. The reason is that it would be very difficult for EagleFiler to keep track of the files within the referenced folder to index them and add tags and notes if it allowed you to freely add, remove, and move them.
Is automatic indexing of “non-aliased” folders – ones that are actually in an EF library as opposed to those referenced via an alias – still something you are considering? This was mentioned some time ago in a thread.
Because of the way the system works with default directories (in save dialog boxes), I think that it is often the case that the fastest way to file project related documents (as opposed to say, downloaded PDFs) is to save them in an existing directory (rather than saving them to the Import folder or somewhere else and then switching to EF in order to classify them). And my preference would be for EF to eventually be the interface for these projects as well (though as it often turns out, my thoughts on this may be confused and inconsistent with EF’s intended use case).
I’m not following your question. What is a non-aliased folder that’s actually in the EagleFiler library? That sounds like a normal folder that you create in EagleFiler, and EagleFiler does index such folders, but since folders don’t really have any content this amounts to indexing the name and notes.
Yes, I’m still considering adding support for saving files directly into a library (rather than into a To Import folder). There’s no question that this would be very useful.
My intended referent was the file system structure of the library and its contents, and saving there directly was just what I had in mind–so you answered it.
Linking: Either a Feature Request or I’m not getting it
I’d like to be able to mix a link to a document with other text in the same document. For instance, I might want to Be able to store my original Omni Outliner notes in the same place I am putting further annotation about the project.
(Note: I really want to use EF as an alternative to VoodooPad or Journler as a way of generating original content within the app, in adddition to being just a nifty file storage system. I understand that I may be pushing the envelope as a result.)
I’ve tried to do this by creating a new RTFD document within EF and linking it to the test OPML file. But there are problems:
– Dragging the file to the document captures the icon, but no link.
– Using the Format=>Link command and dragging the file to the Link entry point gets me a link that Safari attempts (and fails, obviously) to open with an http:// command.
– Importing the document (in this case, an alias of the document, as EF converts the OPML into a text entry, which is not what I am after here) into EF and then dragging that entry to the new record in question does create a link to the original EF entry, but clicking on that link just takes me to the entry, not to the original file intself. Clicking on that then launches OO. But even though this gets me there in the end, it does mean that the document and he file I want to link it into have to be in the same folder.
So, I can do it, but it’s sort of a kludge. Is there a way to follow this bouncing ball without so many bounces?
This is arguably a bug; I’ll try to fix it.
Dragging in a file enters an absolute path for the file. If you type “file://” in front of this (so that it probably starts with “file:///Users/”) then it should be a valid URL for a local file, and it won’t try to use HTTP.
I’m curious why you don’t want EagleFiler to treat OPML files as text. OPML is a text-based format, so by treating it as text EagleFiler can edit it and index its contents for searching. You can still double-click the OPML file to open it in your OPML editor of choice. And this would remove that cumbersome level of indirection.
Right—when you create a link by dragging and dropping a record, EagleFiler creates a link to that EagleFiler record. Such links will continue to track the record, even if you move it to a different folder in the library.
I recommend either importing the OPML file and creating an EagleFiler link to it, or using a file:// link. The latter is more convenient (only one click to open the file in OmniOutliner), but file:// links will break if you move the file or library.
It defaults to “http”. Based on the comment above, I tried editing the link (using the “Edit Link” option) and that worked. I’m sort of surprised that it assumed that a file being dragged off the desktop was somehow an http link – am I missing something here?
Short answer: I think the link bit at the end will work.
Long answer: It’s not so much that I don’t want it to treat it as text most of the time – I do, for exactly the reasons you say. In this case, though, what I am trying to do is create a link inside an entry.
So, I could have as part of my document about a project a summary of the meeting notes, then a link to the meeting notes. I don’t necessarily want to clutter up that particular entry with all of the notes – they are safely stored and accessible – and hence I might not want to have the OPML “in my face” when I am looking at the summary doc. (And actually, I probably NEVER want to see the OPML – in that case, I would cut and paste the contents as text, to leave the ever-useful-but-nonetheless-unsightly OPML code behind.)
Truth be told, though, “meeting notes” isn’t a good example, because those are static. A link gives me the ability to include, for instance, BrainForest files that may still be works in progress.
Rereading this, I realized I should back up and explain something. I’ve got a ton of little snippets, outlines, webpages and the like that were collected with the intent of making them part of a bigger project, like a novel. So, I might have a notes in BF about a particular plot idea or sequence of events, a web page from wikipedia about a particularly interesting historical personage, and notes in a text file about a particular setting. So I can sketch this out in EF, with links to the other source documents. But this example novel idea isn’t fully gelled yet, so I don’t want to start cutting and pasting text that I know may change. I want to keep everything in it’s natural state for the time being, using EF to tie everything together.
EF already allows me to group stuff, through the use of tags, and that’s great. But I want to add some metadata about how those pieces of the puzzle go toegther, not just tag them as being all in the same puzzle.
As I said earlier today, I understand I am trying to put a square peg in a round hole.
I think that will work, now that I know what I was doing wrong.
Links in EagleFiler (and other applications that use the OS’s text system) are URLs. When you dragged the file to the text field in the sheet, it inserted the file’s path. This is arguably an OS bug; the sheet should know that it needs a URL and instead insert a URL for the dragged file. (Perhaps I can work around this.) A path is not a valid URL, since it’s missing the scheme (file: or http:), so the OS tries to make it into a URL, and it assumes HTTP—that’s generally correct, in browsers and such, but in this case it wasn’t what you wanted.
If it’s a RTFD file into which you are dragging the other file, the “icon” is actually a placeholder for an attachment which is copied to the RTFD bundle.
If you open the RTFD document in TextEdit, you can then double-click on the icon to open and edit the attached file, i.e. a limited form of link-back type functionality.
The capability to edit embedded rich text attachments isn’t offered by most programs that support RTFD, as far as I can tell. Given that TextEdit is supposed to demonstrate Apple’s rich text system, I’m not sure why that is the case.
Yes, my current thinking is that EagleFiler should behave the same way as TextEdit in this regard, so I’m going to leave it as-is.
When I organize my files according to projects, than the same file can appear in more than one project, meaning it needs to appear in more than one folder (assuming folder = project in my model).
Therefore, I at least need aliases within the same library; I don’t want to have to copy a file to each folder/project it is part of, because then changes made to a file in Project A’s folder don’t show up in the same file in Project B’s folder.
Tags are a kludge that works if there aren’t many projects, but the system breaks down when you have a lot of projects and a million tags to browse or search through. If tags could be in folders it would work OK, though it would still be sort of a kludge.
What I (and I have the feeling a lot of others, though they might not know it yet really want are groups a la Together. Unfortunately, Together’s group function is fatally flawed, because the groups aren’t hierarchical; instead of having a million tags to simulate pseudo groups, as one would currently have to do in EagleFiler, you’d have a million flat groups in Together.
Conceptually what I want: groups which are exactly like folders, except that they contain references to files rather than copies of the files. And like folders, one group can be placed within another.
Pleeeeease? (Did I mention I’d pay a lot of $$ for that?)
Don’t tags already have both those features? The only difference I see between tags and the hypothetical hierarchical groups is that you can’t have two tags with the same name. In my view, the difference between tags and groups is so slight that it’s not worth the complication of having both.
If I could put tags into folders, or otherwise organize them, I’d be happy. I’d be dedicating the use of tags to another (sort of) use, in the process, I think, losing (or at least diluting the usefulness of) their original purpose, but that’s a price I’d pay.
It doesn’t feel as clean as groups or aliases, but it would pretty much accomplish the same thing.
Nothing like replying to my own message… <lol>…
…but it appears tags have some element of hierarchy to them; tags can be placed within other tags. This requires some exploration – I can probably get the functionality I need out of it. (Is this feature in the docs anywhere? I somehow managed to completely miss it.)
One thing I can already see, though, is that in organizing, the inability to have, for example, a tag hierarchy: “Personal/Financial” and “Business/Financial” is going to be a problem. If the problem is already apparent with the database at such a young age, I can imagine how hard I’ll be gnashing my teeth when the database matures and grows to a useful size.
Yes, this is what I was saying above. Tags can be placed within one another.
I suppose I should add that.
Well, one tag-style way to handle this would be to have three tags: Personal, Financial, and Business. Then you would do a search or use a smart folder if you want to see just the business finances. The nice thing about tags is that it’s easy to apply more than one at a time, because you can type and use auto-completion.
If you really do want a hierarchy, reusing names, with each record appearing in more than one place, then I think folders and aliases (not yet supported, but something I’d like to add if I can figure out how to do it) are the way to go. Then you would have the benefit of seeing and browsing this hierarchy in the Finder and other applications, too.
Perhaps I’m missing something, but I think that between tags and aliases there’s already a lot of functionality covered, and even a bit of overlap. Groups would add complication and don’t really provide anything new.
From my perspective, it makes no difference whether it’s imlemented as aliases or groups. Aliases were actually my first thought, till I realized that Together already had what seemed to be the desired functionality, but called groups. So almost by chance, I ended up talking about groups, rather than aliases. As far as I’m concerned, though, a reference to a file is a reference to a file, whatever you call it. (And also from my perspective, a tag is a different animal than a reference.)
OK, now that I know what to ask for: Aliases, please? Pretty please?