Now drop in some version control (mercurial for my own preference :)) and we are onto a winner.
Dropbox is great for syncing between your development machines, but version control is essential for deployment and team development. Combining the two is really powerful.
Actually no; Dropbox and version control are different ends of the same problem spectrum. Using Dropbox for version control is non-optimal, and Dropbox VC is more backend/invisible to it's use case.
Dropbox is about syncing, as fast as possible and in real time - it is designed for multiple computers but only one concurrent use. So it is really for the individual. Versioning is a form of snap shot that is designed to allow multiple concurrent work (and has benefits for deployment, releases, bug tracking etc.)
The vision should be to see them working together IMO :)
Dropbox definitely has version control, you are able to move back and forth between different versions of a single saved document, that's definition enough. It's just not meant for fine grained control like Mercurial or other DVCS. CouchDB has version control, would you ever use that?
Another "feature" would be the ability to use it without dropbox--save functionality removed. I don't have my dropbox password handy, so the app is completely unusable. (HTML"5" database/ javascript localstorage?)
BTW, I'm the author of this software. So I've been trying to figure out how to save things locally for awhile. I realized that HTML5 has a File System API which in Chrome 9 can FINALLY write to the local SANDBOXED environment. This feature is planned!!
How far do you plan to go with this? You could certainly make a buck or two if, say, you start offering a premium IDE with auto-complete, server-side compilation, etc. Not sure there's a big demand for this. Maybe you could sell this to enterprises and they could just deploy a lots of thin clients--save some cash on powerful workstations--and can log in from anywhere to develop and compile the code server-side and seamlessly deploy. But I'm just thinking out loud now. Best of luck.
I plan to utilize the Dojo's data API as an abstraction layer on top of many different kinds of drivers. I also have thought a bit about what sorts of SERVER side integration this can have - with the potential of websockets, I can see a RESTful git/hg server to be a next logical step!
The Dropbox API supports the standard OAuth web flow which just requires you to have an active session on dropbox.com. I put in a feature request so hopefully soon the extension wont ask for passwords anymore.
As a solution to the bug you mentioned ("The Dropbox API supports the standard OAuth web flow which just requires you to have an active session on dropbox.com"), where you say that you need an active session on dropbox.com to use Dropbox's OAuth API.
Judging by your response, it's clear that there isn't a bug, and you either just don't know how OAuth works or you don't understand what an active session is. OAuth doesn't require an active session on a website, and an active session is having a page loaded in your browser.
> Judging by your response, it's clear that there isn't a bug, and you either just don't know how OAuth works or you don't understand what an active session is. OAuth doesn't require an active session on a website, and an active session is having a page loaded in your browser.
The OAuth web flow requires an active session on dropbox.com. Without an active session Dropbox can not verify who the user is.
You still didn't answer my question about how a frame would help. Iframes should never be used to to embed OAuth provider authorization pages and embedding dropbox.com in general would be pretty useless if the user does not have an active session open.
As far as active sessions go dropbox.com is going to have two kinds authenticated and anonymous. Since we are clearly talking about access to users Dropbox accounts the only type of active session that would be useful would be authenticated.
> You still didn't answer my question about how a frame would help.
I thought you were saying that you couldn't get the Dropbox API authenticated using OAuth working unless you had a continuous active session on dropbox.com. Sorry for the misunderstanding.
This is fantastic. This is exactly how I foresee the future documents and editing. Dropbox, or something like that, provides the service of saving the files. Then web apps are granted access to them and can edit them. Local storage becomes a cache, and Dropbox is where the files are "really" stored.
The advantage of this, of course, is that all your stuff becomes device-independent. Log in from any device that has web access, and you'll have access to all your apps and all your files.
This is much better than having each web app manage files on their own. For instance, you might have documents saved in Google Docs, notes saved in Evernote and Catch.com, and emails saved somewhere else, etc. It sure would be nice to have a single service provide the file storage so that you always have all your stuff and don't have to worry about some web app going obsolete and losing your data along with it.
Now what I would really like for backwards-compatibility is a web-based Linux environment to access my files. Someone recently created a web app using the HTML 5 canvas element (I think) to run an X GUI. (Anyone remember what this was called and where it is located?) Attach a Linux system and that GUI technology to your Dropbox, and then you have an entire computer that can be accessed from any device. Either the browser itself would load all the files and run them by emulation, or a server could run them natively and just print the results to your browser. Either way, once that becomes possible, I would be able to convert to an all-web environment.
That was my initial reaction to this too. But without a compiler/interpreter on hand, this app won't be too useful for any serious coding. You just can't test what you're writing.
On the other hand, this is fantastic for non-code text files.
Little things like icons on the left are really helpful when trying to browse a file structure. In any case, I'll likely be using this once and a while in a pinch since I keep all of my client files in Dropbox.
I'm also excited for the Ace update. This appears to be using a pretty old version. Rendering text in the DOM is much faster.
It looks like both of us are hitting something here. People seem to be VERY enthusiastic about this. I am very excited to have pieced together some amazing technologies.
Joel, I actually saw your app and thought that it was quite amazing looking (it gave me hope in Ace actually!)
I hate being negative, but I really don't see the use case. I have a text editor and Dropbox installed on my machine, why would I want to install this editor?
In the context of something like Chrome OS, stuff like this is vital to being able to do meaningful development work. It's also pretty cool to have your personal development environment, settings, etc. immediately accessible from wherever you may be.
I still don't get it. I would love to use Dropbox but I can't install it everywhere I go since the installation requires admin rights and I don't have them at the university's computer for example. But I can use SSH and therefore SCP from any computer without admin rights, so I really don't see what this does except eliminate the need for a shell account, which are practically free, heck even VPS's are beginning to be almost free nowadays.
I'm pretty sure you don't have to install Dropbox; the app is just using it as local storage 'in the cloud'. It'd be nice if there were an interface to swap it out for other things, like Microsoft, Google, EC2 or Rackspace storage.
I only wish the real Textmate followed up on the huge list of todo's and feature requests people have been submitting. I think a core update is long overdue.
I personally hope the likes of SourceKit and Cloud9 IDE and such will someday replace the likes of Textmate and Eclipse. It'll be a dream when you have VCS, documentation, collaboration, IDE / text editor, running environments all be accessible by everything (including your tablets!!)
This is very interesting. I realize I'm in the minority here, but I would love to use something like this for editing English-language text such as articles, letters, and so forth. This requires decent support for line-wrapping, proportional fonts, and configurable line-spacing. I write my documents in markdown and convert it to whatever is needed - ODT or LaTeX - using the fantastic pandoc. I don't actually write a lot of code; I do write a lot of articles.
I also really like vim keybindings, which makes my usecase even more exotic. Web apps might make this niche interesting.
Nice find. Since this is a text editor, it would be nice to just display text files.
PlainText, my favorite iOS app for note-taking, displays all files from a specific folder within Dropbox. It may be limiting to others, having just have one folder but it keeps things organized. I'd like to see this either support that one folder model or alternatively, hide all content (images/video etc) that don't apply to the editor.
I'm angry at myself for not thinking about the Dropbox portion of the application. I had already thought that a TextMate-like editor for Chrome would be really nice to have, but I couldn't think of a solution for. If I used traditional saving methods, I couldn't figure out why I wouldn't just use emacs, coda, textmate, etc. The Dropbox portion is what makes this app for me.
I'm behind a corporate firewall where Chrome isn't allowed, any-one know of an equivalent which will run on Firefox?
As an aside the Chrome Web Store tantalizingly says "Sorry, we don't support your browser just yet. You'll need Google Chrome to install apps, extensions and themes."- are they planning to go cross-browser at some point or just teasing me?
It looks handy, but upon realizing that it doesn't actually do very much (beyond simple text editing), I discovered http://kodingen.com (has a Chrome app, but really it just sends you to their website). It looks pretty amazing and fully featured so far.
Speaking of DropBox integration: I have the DropBox App on my iPhone, and the 1Password App too, which has "DropBox integration", but it asks for my DropBox password. Is that the way it's supposed to work? Shouldn't 1Password be able to access DropBox files via the phone itself?
I believe 1Password is just using the Dropbox API, in which case your credentials are indeed needed. I don't think it's possible for 1Password to use the Dropbox App to do the integration with the Dropbox service, at least not at the present time with the way apps are sandboxed.
Got it installed but when I try to access the getting started guide I get format not supported? I have no problem viewing web pdf's, even have Acrobat Pro installed. So what's going on?
The only thing I like about this is the code pane as it renders code decent enough. Everything else is a bit unfinished work it looks like. Time to change my Dropbox password then!
This is really cool, but I'm having some issues here, when I open up a directory more than once the directory's that are in that folder duplicate, like say a folder called css, I have a folder named img in it, if I re-open it then it displays to img folders
I was inspired actually by the CR-48. As your JS engines get faster, these sorts of software would be more relevant. I 1st PERSONAL milestone is to develop this very software with itself rather than Textmate :)
The problem of editing text files, synching them across many machines, versioning them and sharing them via web or email is I think a well-solved problem.
Even when one or more of the computers is a public machine (ex. in a library)? This would have been great when I was in college and didn't always want to carry my laptop around.
I just created a dropbox account to test this out. Obviously there are no existing files in it. I looked for a button to create a new file and could not find one.
If dropbox does not have a create file call for you to use, perhaps you could have the app create an empty filename and upload it automatically and then edit it as an existing file?
Edit: Never mind, I finally noticed the buttons on the bottom left. That was quite unintuitive for me--I never look at the bottom left for application buttons. Is this something that textmate does?
That said, this looks quite convenient, and I appreciate you bringing it to my attention!