Jump to content

canadaduane

Member
  • Content Count

    35
  • Joined

  • Last visited

About canadaduane

  • Rank
    Member

Contact Methods

  • Twitter
    canadaduane
  • Website URL
    http://makerhome.ca/

Profile Information

  • Location
    Salt Lake City, UT
  1. How do you have 2 Dropbox copies installed? Or rather, how does Dropbox itself differentiate between the two? I currently use the value stored in ~/.dropbox/host.db to know where the "Dropbox" folder is located on the hard drive. When there are 2 copies of Dropbox installed, where does the 2nd copy store information about itself? A folder other than ~/.dropbox/?
  2. It's certainly possible. I think to do it right, we'd need a configuration page or something... some way to indicate where to send the files. And while we're at it, probably an option to copy vs. move them.
  3. Ok, I figured it out. The API library was asking for a "media" link in the case of direct URLs, and directories are not considered "media". The latest at http://db.tt/A3eZqMAr should fix it. Duane
  4. BTW, the workflow has been approved for "production" by Dropbox so as many people as would like to use it, should be able to now. I had to remove the dropbox icon from the workflow (at least for approval--my personal copy uses the logo anyway Here are the branding guidelines: https://www.dropbox.com/developers/reference/branding Here is the "approved" workflow with changed icon (also, renamed to "Dropbox Quick Links"): http://db.tt/A3eZqMAr Duane
  5. Here's what I get in the Console.app log: Alfred Workflow[22033]: Creating a link for a directory is not allowed. (Dropbox::API::Error) [query: /Users/duane/Dropbox/Books]
  6. I've applied for a "production" license for the app at Dropbox. I'm not sure what they'll do--I've never applied for one before. If you want to access it in the meantime, you can get your own development key for the app, and then replace the dropbox_app_key/dropbox_app_secret in the bundle_settings.yml file in the workflow's directory.
  7. Good call. I hadn't noticed that the underlying dropbox-api library didn't offer support for this. I fixed it and sent a pull request to the original library. In the meantime, the workflow has been updated and re-downloading the link above should give you a version that supports getting links for folders as well. Duane
  8. Reload the original download and you should get a new Command+Shift+Ctrl+D hotkey for a direct URL link to the file. I also trimmed the file a bit, so it's under 2 MB now Duane
  9. Yes, the full URL is supported by the dropbox-api ruby gem. Maybe I could create a Command+Shift+Ctrl+D alternative for the full link?
  10. Yeah, it comes with several Ruby gems as well as images for the HTML "success" page. Some of it could probably be trimmed down, but in today's bandwidth I didn't think 3MB would be an issue.
  11. For any file in your Dropbox folder, this workflow shows the dropbox short link URL (e.g. http://db.tt/1LkWGVJF) and copies the link to the clipboard (Cmd+Shift+D): 1. Select a file in Finder (must be a file within your Dropbox folder, e.g. ~/Dropbox/Photos/MyPhoto1.jpg) 2. Press Command+Shift+D 3. Authorize the workflow to use the Dropbox API (only if this is the first time) 4. The shortened link pops up and is copied to the clipboard. It uses OAuth in the background to connect to Dropbox so you can authorize the Alfred 2 Workflow without storing passwords insecurely. For those who are interested, it starts a Ruby-based local web server using Sinatra which is then opened in the default browser. You can authorize the Dropbox app in your browser, and then the local server shuts itself down. Once authenticated, you don't need to do this step again. Once connected via OAuth, this workflow has the potential to do a lot of things with Dropbox, but currently only queries the dropbox service for shortened URLs. This method (using OAuth/dropbox) has the advantage that any file in your Dropbox folder can be shared, not just those in the "public" directory (a deprecated method of accessing dropbox files). The downloadable workflow itself is here (on dropbox, naturally): http://db.tt/1LkWGVJF http://db.tt/A3eZqMAr (new version, fixes direct linking to folders) And the github repository is here: https://github.com/canadaduane/alfred2-dropbox Duane
  12. My use case: I have a *partial* local store of "issue tickets" as well as a *complete* remote store of tickets. When the user types "ticket <search term>" I want to be able to show tickets that have previously been cached in the local store. A "cache hit" is a likely scenario: users often search for tickets that they have previously visited. However, it isn't good enough to only show tickets in the local store IF there are further matching terms, OR there have been remote updates to tickets previously cached locally. Therefore, I would like to show an initial list of matches, followed by an updated list of matches. (The list of matches may contain the same number of items, but with updated titles, OR the list may increase or decrease in size). Agreed, it doesn't make sense for local data retrieval. I think the above list of people seeking a solution shows that many people are looking for something not optimally handled by Alfred at the moment. I won't speak for Andrew, but I can imagine several ways where this could be done efficiently. The most obvious is just to keep the selection at the same place in the updated list as where it was in the previous list (i.e. using the uid to match item identity). Otherwise, just replace the old list with the new list. No merging involved (i.e. the only state held between updates is the uid of the selected item). I'd like Alfred to be a little snappier in spite of possibly slow server response times Duane
  13. Looking through past posts, it looks like many of us workflow developers are encountering a similar problem: how do we both [a] respond quickly to user input and send results to Alfred, and load data from slow external sources that we depend on to show results to Alfred. Here are several discussions about this topic, from different angles: Displaying Items As They Echo http://www.alfredforum.com/topic/228-displaying-items-as-they-echo/ Refresh script filter xml after first echo http://www.alfredforum.com/topic/222-refresh-script-filter-xml-after-first-echo/ Refresh workflow http://www.alfredforum.com/topic/215-refresh-workflow/ Workflow script filter with one-shot completion http://www.alfredforum.com/topic/142-workflow-script-filter-with-one-shot-completion/ Ability to buffer input for script filters (Wait until user is finished typing before calling script) http://www.alfredforum.com/topic/91-assorted-feature-requests/ I think that the best solution proposed so far is tomhunt's: allow the xml to be replaced by new xml later on in the script execution, or in other words, allow script filters to resend the results to Alfred as many times as desired. This seems to solve the problem neatly in several ways: If scripts have local storage with cached results, they can immediately send a preliminary list to Alfred. While the script is working in the background to retrieve data from the internet, other keypresses can still re-execute the script for updated cached results Once the script has retrieved its data from the internet, it can again push a final list of results to Alfred. For scripts that have partial information at first (such as cached names or IDs of items) and later get data from one or more internet requests, the results list can be updated as desired to reflect new information. Duane Johnson http://makerhome.ca/
  14. +1 to JSON output for script filters. XML is heavy.
×
×
  • Create New...