Jump to content

Jasondm007

Member
  • Content Count

    191
  • Joined

  • Last visited

  • Days Won

    6

Jasondm007 last won the day on July 9

Jasondm007 had the most liked content!

About Jasondm007

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @deanishe Agreed - it's just a problem in Alfred's preferences, as described above. And, to be clear, it's a relatively minor UX problem in the scheme of things. For the most part, I really like Alfred 4's new look. While the point about dark themes and usability across light and dark themes is fair, it's odd to rule out the use of dark iconography now in Alfred's preferences. Ignoring Alfred's longstanding use of gray/light backgrounds and black typography, there are a lot of people with vision-related issues that depend on white/gray/light backgrounds and dark text/icons for legibility purposes. Not to mention the fact that Alfred's own icon is hardly visible in the settings described above. Take a look at the screenshots below. Why create visibility constraints that even the app's own icon doesn't work well under?
  2. I’ve posted this as a bug but, in fairness, it’s a feature of Alfred 4 (and not a bug). Namely, some aspects of Alfred 4’s new GUI are too dark to be legible in some use cases - particularly for those who use dark iconography. In the workflows section of Alfred’s Preferences, this problem manifests itself where the icons are displayed in the inner sidebar and in the informational portion at the top of the window. In the screenshots below, note how difficult it is to see the black search / magnifying glass icon? For me, it’s more of a functionality problem than an issue of aesthetics, as I rely on the sidebar icons to quickly find the workflow I’m looking for. While the text looks good, unfortunately, the icons are no longer visible in Alfred 4. Workflows - Sidebar Workflows - Informational Portion (top of screen) The second place where this issue comes up in Alfred’s Preferences is when viewing Snippets. While this problem also involves the use of black iconography - for snippet Collections, specifically - it’s only visible to those who use MacOS in dark mode (but use a light Alfred theme). In these cases, the background color behind the collections’ windows is dark, making black icons impossible to see (see screenshot below). Features - Snippets - Collections Window There are a ton of ways these issues can be fixed, so I thought I'd throw out a few: Easiest fix: use lighter background colors in these cases (e.g., flipping the two purple colors in the sidebar, so the dark is on the outside) (e.g., going with a lighter gray/black in the upper information) Another fix: add another display option with a lighter color, such as those accessed via the gear next to Alfred's workflow filter (screenshot below). However, something else would have to be done about the snippets/collections problem, since it lacks such options. My favorite fix: add a color palette option to Alfred's main preferences. Personally, I like OmniFocus' approach, which provides users with three options for: automatic, light, and dark modes (see screenshot below - they call the "light" version, just plain old OmniFocus). Here, the automatic mode would just follow the MacOS designation, and the others would allow users to manually place Alfred in either mode. Among other things, this would entail creating a light mode - or in keeping with OmniFocus, just a plain old "Alfred" mode - where the issues outlined above are easier to see (in addition to maintaining the lighter toolbar, which Alfred already does when MacOS is not in dark mode). Thanks for your consideration!
  3. Thanks, @vitor!! I didn't realize that first screenshot was from the menu bar / status menu. That's pretty neat! Is it possible to view the remaining time from Alfred, too - or is it status bar only? Thanks. Cool project, too!
  4. @vitor I was thinking about replacing my current pomodoro timer with another tool that was a little more Alfred-friendly, when I came across your workflow. This looks fantastic! Thanks for sharing. One quick question: Does your workflow tell you how much time is left on the timer? It doesn't look like it does, but I just wanted to make sure. From what I can tell from the app's GitHub page, it doesn't look like it's possible to either. Thanks for your help!
  5. @dfay Thanks for giving it a try! I really appreciate it. I'm not sure what the deal is with Mojave's tags features. Even the old tags shortcut doesn't work without removing favorites or other odd workarounds. Let's keep our fingers crossed they address some of this in Catalina. ... I won't hold my breath.
  6. Great idea, @vitor!! @Andrew - Any chance we can get this butler on steroids? 😜 I'd love to start using Alfred's buffer more. Thanks for your consideration!!
  7. I would love to start using Alfred’s file buffer more often, especially with some of the nice additions made in Alfred 4. However, Alfred is in dire need of better Finder-Buffer integration. Either of the following would solve this: a File Action that adds files to the Buffer, or a Hotkey that can be used to add files directly from Finder to the Buffer (i.e., in Preferences → Features → File Search → Buffer). Under the current setup, the ability to use a hotkey to file action files from Finder is great (Preferences → Features → Actions → Selection Hotkey), but it doesn’t help with situations where you want to action the file more than once. Several people have created workflows that effectively mimic Allred’s keystrokes, but they’re all pretty fragile (example). In addition, I still haven’t found any that work with multiple files. This feels like something that ought to be addressed on a system-wide basis. Alfred’s a great butler, but I think he can carry even more things! 😉 Thanks for your consideration.
  8. @dfay By chance, do you know how to target Finder's "All Tags.." view (accessible most easily through the sidebar, when enabled)? I tried to create a simple workflow that opened Finder to this view, and have not had any luck. It seems to behave quite differently from most. Thanks
  9. @dfay Unfortunately, my previous suggestion had the unintended side-effect of retaining the page info from Preview - which takes up a ton of space in the output (e.g., page 1 of 350, etc.). To fix this, I just added an IF/THEN statement to use the original code for Preview's windows, and the abbreviated version for other things. I don't have Skim on my machine, so I didn't add anything special for it. I suspect that you'll want to treat it like Preview (i.e., the original code)? Here's the relevant portion of the "active_window" script: set theWindows to {} set appsForWindows to {} repeat with theApp in appList tell application theApp set itsWindows to every window repeat with w in itsWindows if ((theApp as string) is equal to "Preview") then -- Added by Jason set theWindows to theWindows & {{theApp as string, name of document of w, id of w}} else -- Added by Jason set theWindows to theWindows & {{theApp as string, name of w, id of w}} -- Added by Jason end if -- Added by Jason end repeat end tell end repeat Yeah, you're definitely right about PDF Expert. I asked them about a different script-related question previously, and got brushed off. I don't think they'll ever add it. That issue seemed like it was a little more complicated than grabbing a document/window's name, however. I'm a little surprised that it doesn't work here. Isn't that limited amount required? In any case, maybe I'll have to switch to another PDF reader/annotater some day. For the most part, I use Preview. However, I've always liked the simplicity and aesthetic of PDF Expert better - so I use it when I'm reading for longer periods. Its layout for annotations and bookmarks is a lot cleaner than Preview's. I also have Adobe Acrobat Pro DC and Abby FineReader, but I'm not a big fan of these apps when just reading or taking notes. I assume from the script that you're a Skim user, right? Out of curiosity, what do you do about the embedded annotations issue (assuming it's still an issue)? I never tried Skim because I hated the idea of having to remember to export each PDF after adding something to it. It's GUI always struck me as a little dated, too (but functional, nonetheless). Unrelated, but were you thinking about displaying each supported app's icons in the workflow's output? I ask because I noticed the images in the workflow's folder (and think it's a good idea, too). However, they've never shown up on my computer - even before I started screwing around with it. My output just shows the generic orange four squared icon from Alfred for all windows/apps.
  10. @dfay I was tinkering around with the Active Windows workflow, and I noticed that a small tweak to the "active_window.scpt" helped it start working with the OmniOutliner app. Namely, if you remove the "document" reference when you're grabbing the app/name/id, it seem to work. I've copied the relevant version of the script below, commented out the original line, and added a notation to the new line in screenshot below. set theWindows to {} set appsForWindows to {} repeat with theApp in appList tell application theApp set itsWindows to every window repeat with w in itsWindows #set theWindows to theWindows & {{theApp as string, name of document of w, id of w}} set theWindows to theWindows & {{theApp as string, name of w, id of w}} -- Added by Jason end repeat end tell end repeat I still haven't had any luck getting it to work with PDF Expert, but I'll keep toying with it. Do you ever use this app? Unfortunately, I suspect that it's not scriptable. All the best!
  11. I'd love to see each file's tags listed in the information provided by File Navigation's Preview Panel. Tags seem more important than most of the info that is currently listed (e.g., app the file opens in, date created, etc.). Why not list the file's tags there? At the moment, Alfred doesn't have an easy way for viewing or modifying tags, and this seems like a good first step that won't demand a complete overhaul of anything. Ideally, I'd love to see Alfred have its own file action for tags, too, which allowed users to view the file's current tags and modify them as needed (without requiring users to remember their list of tags, etc.). Relying on Finder's "get info" feature is a little clunky, as it requires leaving Alfred, etc. I have some workflows for adding or removing tags that I often use, but they're not very flexible (e.g., they don't tell me which tags are already on the file, they don't dynamically tell me which tags are in use on my system, etc.). Lastly, I'd love to see tags visually incorporated into Alfred's main search results (favorite suggestion here), but I guess that's for another day! Thanks for listening!
  12. Please ignore this file filter bug report, as it appears to be working with contacts now. I have no idea why it wasn't working yesterday. I restarted my computer a few times before posting to this forum. The only difference between yesterday and today, that I can think of, is that I did a full shut down. My apologies for the false alarm (though the sidebar still stands). Thanks again for all of your help!
×
×
  • Create New...