Jump to content

Search the Community

Showing results for tags 'tutorial'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Alfred 3
  • Make the Most of Alfred
    • Discussion & Help
    • Bug Reports
    • Alfred Feature Suggestions
    • Themes
  • Alfred Workflows
    • Share your Workflows
    • Workflow Help & Questions
  • Alfred v2 Themes
  • Alfred Remote for iOS
    • Alfred Remote Discussion & Help
    • Remote Connection Troubleshooting

Categories

  • Articles
    • Forum Integration
    • Frontpage
  • Pages
  • Miscellaneous
    • Databases
    • Templates
    • Media

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Twitter


Website URL


Jabber


Location


Interests

Found 9 results

  1. I’ve been seeing a lot of workflows that need to interact with a browser via AppleScript (usually to get a page’s url), but most of them seem to settle on a single browser (usually Safari), which is a shame. I can certainly understand — applescript is a pain, and since each browser implements this functions however they want, finding the best way to do it with each one can be difficult, so here’s the code for some of them. The code for this might seem massive, but is actually short. Read the comments to understand when to use what. You can find the latest version of this as a gist. -- AppleScript -- -- This example is meant as a simple starting point to show how to get the information in the simplest available way. -- Keep in mind that when asking for a `return` after another, only the first one will be output. -- This method is as good as its JXA counterpart. -- Google Chrome tell application "Google Chrome" to return title of active tab of front window tell application "Google Chrome" to return URL of active tab of front window -- Google Chrome Canary tell application "Google Chrome Canary" to return title of active tab of front window tell application "Google Chrome Canary" to return URL of active tab of front window -- Chromium tell application "Chromium" to return title of active tab of front window tell application "Chromium" to return URL of active tab of front window -- Opera tell application "Opera" to return title of active tab of front window tell application "Opera" to return URL of active tab of front window -- Vivaldi tell application "Vivaldi" to return title of active tab of front window tell application "Vivaldi" to return URL of active tab of front window -- Brave tell application "Brave" to return title of active tab of front window tell application "Brave" to return URL of active tab of front window -- Safari tell application "Safari" to return name of front document tell application "Safari" to return URL of front document -- Safari Technology Preview tell application "Safari Technology Preview" to return name of front document tell application "Safari Technology Preview" to return URL of front document -- Webkit tell application "Webkit" to return name of front document tell application "Webkit" to return URL of front document -- This example will return both the title and URL for the frontmost tab of the active browser, separated by a newline. -- Keep in mind that to be able to use a variable in `tell application` — via `using terms from` — we’re basically requiring that referenced browser to be available on the system. -- That means that to use this on "Google Chrome Canary" or "Chromium", "Google Chrome" needs to be installed. Same for other browsers. -- This method also does not exit with a non-zero exit status when the frontmost application is not a supported browser. -- For the aforementioned reasons, this method is inferior to its JXA counterpart. tell application "System Events" to set frontApp to name of first process whose frontmost is true if (frontApp = "Google Chrome") or (frontApp = "Google Chrome Canary") or (frontApp = "Chromium") or (frontApp = "Opera") or (frontApp = "Vivaldi") or (frontApp = "Brave") then using terms from application "Google Chrome" tell application frontApp to set currentTabTitle to title of active tab of front window tell application frontApp to set currentTabUrl to URL of active tab of front window end using terms from else if (frontApp = "Safari") or (frontApp = "Safari Technology Preview") or (frontApp = "Webkit") then using terms from application "Safari" tell application frontApp to set currentTabTitle to name of front document tell application frontApp to set currentTabUrl to URL of front document end using terms from else return "You need a supported browser as your frontmost app" end if return currentTabUrl & "\n" & currentTabTitle // JavaScript for Automation (JXA) // // This example is meant as a simple starting point to show how to get the information in the simplest available way. // Keep in mind that when asking for a value after another, only the last one one will be output. // This method is as good as its AppleScript counterpart. // Google Chrome Application('Google Chrome').windows[0].activeTab.name() Application('Google Chrome').windows[0].activeTab.url() // Google Chrome Canary Application('Google Chrome Canary').windows[0].activeTab.name() Application('Google Chrome Canary').windows[0].activeTab.url() // Chromium Application('Chromium').windows[0].activeTab.name() Application('Chromium').windows[0].activeTab.url() // Opera Application('Opera').windows[0].activeTab.name() Application('Opera').windows[0].activeTab.url() // Vivaldi Application('Vivaldi').windows[0].activeTab.name() Application('Vivaldi').windows[0].activeTab.url() // Brave Application('Brave').windows[0].activeTab.name() Application('Brave').windows[0].activeTab.url() // Safari Application('Safari').documents[0].name() Application('Safari').documents[0].url() // Safari Technology Preview Application('Safari Technology Preview').documents[0].name() Application('Safari Technology Preview').documents[0].url() // Webkit Application('Webkit').documents[0].name() Application('Webkit').documents[0].url() // This example will return both the title and URL for the frontmost tab of the active browser, separated by a newline. // This method is superior to its AppleScript counterpart. It does not need a "main" browser available on the system to reuse the command on similar ones and throws a proper error code on failure. const frontmost_app_name = Application('System Events').applicationProcesses.where({ frontmost: true }).name()[0] const frontmost_app = Application(frontmost_app_name) if (['Google Chrome','Google Chrome Canary','Chromium','Opera','Vivaldi','Brave'].indexOf(frontmost_app_name) > -1) { var current_tab_title = frontmost_app.windows[0].activeTab.name() var current_tab_url = frontmost_app.windows[0].activeTab.url() } else if (['Safari','Safari Technology Preview','Webkit'].indexOf(frontmost_app_name) > -1) { var current_tab_title = frontmost_app.documents[0].name() var current_tab_url = frontmost_app.documents[0].url() } else { throw new Error('You need a supported browser as your frontmost app') } console.log(current_tab_url + '\n' + current_tab_title) Other browsers Firefox Absent since although it’s possible to get the window’s title, it’s not possible to get its URL (it used to be, before version 3.6). It’s possible via hacky ways that consist of sending keystrokes, but those can be unreliable. This bug is being tracked in Bugzilla.
  2. Introduction Alfred workflows are simply zipped directories with an altered extension. Those are great news if you want to automate packaging your workflows for distribution, as you can simply (using ditto in this example, but zip would work just as well): ditto -ck "{{/path/to/your/workflow_directory}}" "{{/path/to/your/output_file}}.alfredworkflow" And that’s it. A zipped directory of your workflow with the custom .alfredworkflow extension. Names enclosed in double curly brackets are examples (they dependend on your situation and must be edited accordingly). Problem The trouble with that solution is that it packages your workflow as it is. Most of the time that won’t be a problem, but it becomes one when you have Workflow Environment Variables with “Don't Export” activated. Alfred knows not to save the value of those variables when exporting your workflow, but your zipping utility does not. Because of that, if you want to package your workflow yourself you need to set those variables (and only those) to empty values. Solution # You need only set these two variables, and the rest will work as is readonly workflow_dir="{{/path/to/your/workflow_directory}}" readonly output_file="{{/path/to/your/output_file}}.alfredworkflow" if /usr/libexec/PlistBuddy -c 'Print variablesdontexport' "${workflow_dir}/info.plist" &> /dev/null; then readonly workflow_dir_to_package="$(mktemp -d)" cp -R "${workflow_dir}/"* "${workflow_dir_to_package}" readonly tmp_info_plist="${workflow_dir_to_package}/info.plist" /usr/libexec/PlistBuddy -c 'print variablesdontexport' "${tmp_info_plist}" | grep ' ' | sed -E 's/ {4}//' | xargs -I {} /usr/libexec/PlistBuddy -c "set variables:'{}' ''" "${tmp_info_plist}" else readonly workflow_dir_to_package="${workflow_dir}" fi ditto -ck "${workflow_dir_to_package}" "${workflow_file}" So, what does this do? Check the info.plist in your workflow directory for the variablesdontexport property. If the property does not exist, package your workflow directory without any modifications. Our work is done. If the property exists, copy your entire workflow to a temporary directory (we’ll make changes to the info.plist and don’t want to do them on our current one). Check every variable in variablesdontexport and set them to empty values in the info.plist of the copied directory (we don’t want to outright delete the variables as the reference would be lost as well). Package the copied directory. Our work is done. Solution as a script #!/bin/bash readonly workflow_dir="${1}" readonly info_plist="${workflow_dir}/info.plist" if [[ "$#" -ne 1 ]] || [[ ! -f "${info_plist}" ]]; then echo 'You need to give this script a single argument: the path to a valid workflow directory.' exit 1 fi readonly workflow_name="$(/usr/libexec/PlistBuddy -c 'print name' "${info_plist}")" readonly workflow_file="${HOME}/Desktop/${workflow_name}.alfredworkflow" if /usr/libexec/PlistBuddy -c 'print variablesdontexport' "${info_plist}" &> /dev/null; then readonly workflow_dir_to_package="$(mktemp -d)" cp -R "${workflow_dir}/"* "${workflow_dir_to_package}" readonly tmp_info_plist="${workflow_dir_to_package}/info.plist" /usr/libexec/PlistBuddy -c 'Print variablesdontexport' "${tmp_info_plist}" | grep ' ' | sed -E 's/ {4}//' | xargs -I {} /usr/libexec/PlistBuddy -c "Set variables:'{}' ''" "${tmp_info_plist}" else readonly workflow_dir_to_package="${workflow_dir}" fi ditto -ck "${workflow_dir_to_package}" "${workflow_file}" echo "Exported worflow to ${workflow_file}." To use that script, give it a single argument: the path to the workflow you want to package. It’ll save it to the Desktop with the name automatically determined.
  3. Just to let you know, my latest Alfred tutorial is now live: https://computers.tutsplus.com/tutorials/exploring-alfreds-latest-features--cms-27910
  4. I just had a tutorial published recently on JSX programming with examples in Alfed: https://computers.tutsplus.com/tutorials/a-beginners-guide-to-javascript-application-scripting-jxa--cms-27171 Check it out.
  5. I really love workflows and I wanted to start creating my own. I'm mostly a front-end developer and use ruby for the most part on any back-end dev work I do. I saw that Alfred supports Ruby workflows which made me very excited. I did some googling and had a hard time finding some tutorials about creating workflows with ruby, plenty with php though. I needed to learn the basics of workflows and wanted to do it in a language I knew (not familiar with php). I wrote a post detailing how a basic workflow functions with ruby. It's nothing you can't find anywhere else, but it was a good exercise to get the basics figured out and create something that helps me weekly. http://buddylreno.github.io/adventures-with-alfred-a-basic-ruby-workflow/ I look forward to all the interesting workflows people are creating!
  6. I've written a fairly detailed tutorial on writing Alfred Workflows in Python as part of the documentation for my new Python Workflow library. Might be of some interest to budding Python Workflow developers, and possibly an interesting trick or two for older hands.
  7. Hi - I was following along with the "Creating a File Filter Workflow", on Alfred's Support website, and discovered a (possible) bug. The URL: http://support.alfredapp.com/tutorials:file-filter-workflow Line 5 says 'Drag a folder to the "File types" box so that Alfred knows you want to search for Folders only.', but the purpose of this workflow is to search into .PDF files, and so should return a list of PDF files, and not Folders. The graphic which illustrates this line correctly shows that the File Types should be "com.adobe.pdf Portable Document Format (PDF)" files. Line 5 SHOULD say: 'Drag a PDF file to the "File Types" box so that Alfred knows you want to search for PDF files only.'
  8. AlfredLite is a lightweight modular framework for creating workflows. Features Modular designOnly load the modules your workflow uses Faster load times (execution speed is an underappreciated feature of any workflow) Less bundeled dependencies Subclassable workflowsAlfred::Workflow is designed to be subclassed, the possibilities are endless! Requirements AlfredLite is tested against the following verions of Ruby: 1.8.7 (preinstalled on OS X Mountain Lion) 1.9.3 2.0.0 (preinstalled on OS X Mavericks) Contributing (aka I can't do this alone!) Bug FixesReporting bugs is encouraged and greatly appreciated, send them here. If you're contributing a bug fix, please make sure you're committing your fixes on the develop branch (bonus points for creating a dedicated bug fix branch). Feature RequestsHave an idea that will help make writing your workflows easier? Then submit it here. Available on Github Updates 2013-06-02: The first release of AlfredLite was made available today, it can be found here. Next up on the list of todos: a settings module.
  9. Hey Guys, This is kinda a shameless plug but I wanted to share it because I think it may be helpful to some people. If you don't want to read this because it's a shameless plug, I understand. If you are considering purchasing the Powerpack, and are unsure of what it really does, or if you own it and are looking to learn more about the features it provides, I wrote a tutorial for MacTuts+ which was posted today. The second part of the article will be posted tomorrow, and I encourage you to take a look at them if you want to learn more. Today's is the basics, while tomorrow focuses on Workflows — understanding them, using them, and creating them. Up and Running With the Alfred Powerpack — The Basics: http://bit.ly/190gcr1 Up and Running With the Alfred Powerpack — Workflows: http://bit.ly/11wN321 Thanks for reading and I hope you find it helpful! -Kevin Kirsche
×
×
  • Create New...