Nice! Would love to have a “quick open” prompt, with fuzzy matching, that most IDEs and code text editors have. Is this on your radar at all?
I don’t see the advantage of a parallel file system, as LibraryView seems to be. So, I disagree with aharpole and others that this is an improvement. It is a little like SImpleNote or any number of apps that have an index in a column to the left and the contents in a pane to the right. I personally find it more useful to just use the host file manager (that is, the Finder). You’ll end up duplicating the file system presentation and worrying about how to do things like backup, exchange, syncing and filtering each index (and other additions that people are asking for here). Nonetheless, assuming you’ll proceed …
Since you already make the best outliner on the market, why not organize the index (the list of file names) using a scheme like TaskPaper? Then people could manually order files, as esotaria suggests. You could even add checkboxes or tags to the file names (though maybe more elaborate than what you want).
I agree about the file name extensions, though I think it should just follow the user’s OS settings for this.
I dragged a text document from the Finder into LibraryView and (for me) the behaviour was unexpected because the document disappeared from Finder. (I had expected it to work like BBEdit, where the document appears to ‘coexist’ in two places.)
I dragged the same file back out of LibraryView into the Finder and, as expected, it disappeared from LibraryView to appear in the Finder.
I then found the LibraryView folder on iCloud and, surprise, the text file was still in there. This suggests that at some stage a duplicate was made?
New should be renamed
New Library and that
New in Window should simply be
One thing I’d like, but didn’t experience - if I right click a folder and select new file I expected the file to be created in the folder - it wasn’t.
Is this a bug or a feature?
If you are just looking at a simple library view I would ask what it will achieve more than finder? Currently I have a library view in finder. It needs to provide something Finder doesn’t for it to have merit for me. The following would be great:
- I think reordering is a must (date or alphabetically)
- Smart folders? I could see a great use in being able to create folders that would look for dates or #tag text. It would be awesome in TP to be able to create a folder with “Due this week” and set it to search for all projects and tasks with a due less than 7 days. I understand that this adds way more complexity to the idea. Ulysses does this exceptionally well.
I think you have iCloud Drive disabled? … you’ll likely see other bugs with that window when trying to save. (I’ll post a fix later today) You should still be able to see a library view if you just drag and drop a folder onto the app icon.
I think there are two main benefits:
Transitioning from viewing a file in the finder to an open document in an app is a somewhat big context switch. I think it’s much faster to do this in app … so you get same view as finder, but you just select a file to see and started editing it … instead of having to double click, switch out of Finder, and into new app.
This view is a nice alternative to using tabs. It allows you to work with multiple documents (and they maintain state, such as selection, undo, etc) all within a single window.
I don’t expect this in first version, but down the line maybe.
Thanks… bug, I agree it should work the way you suggested.
Yes. This is my work Mac, and we have iCloud disabled here.
I’m not sure … sublime also works the way that you suggested … the file isn’t moved. But I think it makes the UI harder to understand when it works that way. It seems to me that if you drag and drop a file into the library it should move to the library. If you just want to open the file you can drag and drop the file to the application icon to open it in place, without moving it to the library.
I’m not able to reproduce this last part. For me when I drag a file out of the library view and into the finder it is also removed from the library. Can you try to recreate this behavior and give me the exact steps to reproduce the problem? Thanks!
Your job is to make sure it’s ignorable and stays hidden once you’ve hidden it It is very much a duplication of Finder behavior, but I still think it’s worthwhile for multi-file workflows. I think it makes switching between files much easier. Also there have been a long line of support questions from users who want TaskPaper to reopen there previous documents … TaskPaper can already do this (if you just leave your documents open when closing, they will be restored). But people often forget. This way your “library” of documents is always presented when you open TaskPaper or created a new window… I think that could help that use case problem a lot.
Unfortunately this would make the implementation quite a bit more complex and prone to bugs I think. Right now the only job is to observer and present the file system. If I maintain my own ordering then I need to start managing a metadata file to store that information. It seems simple, but I think would get complicated.
I hadn’t thought of it, but good idea. I don’t expect to add that into this demo app because it doesn’t have any infrastructure for presenting a good fuzzy match UI. But it should be easy to add to TaskPaper which already has such a UI. So once I start adding this code to TaskPaper I’ll try to remember to do that.
It would be in its own column… so with everything open TaskPaper would have three columns. I plan to change the styling of TaskPaper’s current “projects” column to be a “content list” (non transparent background) and this view will take over the “source lists” (transparent background) style.
Yes it’s built in swift. And intended to be fairly strait forward to plug into an existing document based app architecture. I don’t think I want to open source it at this point, but if there are any friendly developers out there who could make use of the code please email me. I’d be happy to share and get a few more eyes and apps testing it.
Definitely something I’d like to do eventually, but will probably postpone till after I get the current base behavior integrated.
This won’t happen for the Library View example app … I’ve just created it to quickly test the library view and it has no infastucture for handling links, etc. But I plan to add things like this to TaskPaper. The library view solves sandboxing problems that make linking between separate documents difficult … should be nicer once this code is integrated.
Hum … I’m not sure if this is correct behavior or not. On one hand it seems sensible to open in same window… on other hand it seems that opening a document should never replace an existing document view. I’m not sure, but think I’ll probably keep current behavior as it seems a little less confusing.
Yes, just one root folder per view.
I’m not quite sure what you mean, can you give some examples?
Yeah this is a case that I haven’t quite found a solution to yet.
Unfortunately I can’t implement as you suggest because of Sandbox restrictions. When the user opens a file the system gives my app read/write access to that file, but not to it’s owning directory. That’s why it works if you drag the owning directory to the app … then you are giving the app read/write access to that entire directory hierarchy and I can show a library for that folder. (My app always has read/write access to it’s iCloud library, so that’s why I’m able to always show that).
I just looked at iA Writer and they solve the problem by showing an import button and explanation text in the library view when you are viewing a document that’s outside the library. But that seems kinda funky to me.
Another option might be to just disable the library view (hide it and don’t allow showing it) when you open a document that’s not already in the library. That’s a nice clean solution, but maybe confusing because you’ll wonder why “show library” doesn’t work.
Anyway, I’m open to suggestions… but alas when you open a file outside of the library I can just show the containing folder as the library as would seem to make the most sense.