Jump to content

vitor

Community Hero
  • Content Count

    3,895
  • Joined

  • Last visited

  • Days Won

    285

Posts posted by vitor

  1. 2 hours ago, gingerbeardman said:

    It seems Raycast have done a few things different which has given them traction

     

    You missed the biggest one: millions of dollars in VC funding. That’s quite difficult for Alfred to go up against with a two-person team for everything in the business. When you have money to burn, it’s easy to offer features for free despite a big team. That’s not to say you’re wrong on the other points—you’re not—but Alfred’s team has to (more) carefully choose where to invest their time.

     

    3 hours ago, gingerbeardman said:

    There are many more along this line, with many developers stating that they are switching from Alfred to Raycast citing things that were already possible in Alfred. They were obviously unaware of these things.

     

    I agree that’s a hurdle, but it’s not immediately clear how to clear it. It doesn’t help that Raycast themselves misrepresent (or outright lie about; I can’t say) what Alfred can do. I’ve seen it in the wild once or twice.


    Also note that their money buys them hype, and developers are inherently interested in new things. Their business model isn’t yet clear—will they be subscription-based, one-time purchase, will they sell your data before being bought by another company that will kill the app? And are they even targeting the same users as Alfred? From what I gather of their still closed API, their extensions will be exclusively built with code, which ignores a huge chunk of Alfred’s users (non-coders can and do make Workflows) and may not allow as much versatility (I don’t know). I could go on.


    That doesn’t mean it isn’t worth looking into Raycast. All I’m saying is it’s too soon to imagine a doomsday scenario for Alfred because of it. Besides being new and loaded, are they that different from other alternatives, such as Launchbar (not rhetorical)?

     

    3 hours ago, gingerbeardman said:

    Alfred workflow discovery is actually very difficult for users. 

     

    That’s another one where I agree with you. But it’s also another one without an immediate solution. There are quite a few websites for discovering Workflows, but (in my view) none of them are up to snuff after Packal. Partly because—in agreement with a comment on the YouTube link you posted—it can be hard to identify a dead Workflow. That said, I don’t think it’s fair to lunge that criticism at Alfred on a direct comparison to another tool which hasn’t existed for long enough for that to be an issue. I see no reason why they would be immune to that.

     

    3 hours ago, gingerbeardman said:

    To get back on topic, if workflows are already managing API and tokens themselves in a whole variety of ways, it seems obvious to me that an official way to do that with a unified interface/experience could only be a good thing for users?

     

    It’s been discussed at length on this issue why that’s not necessarily true. It’s a feature the vast majority of Workflows would not benefit from, hard to tackle, and at the mercy of the whims of third-parties. And to do all that you need time, which will not be used for something else. Yes, if that feature were implemented and maintained without effort (or done by someone else in a third-party tool, as suggested above) it could be a good thing. But it has a major tradeoff as it stands. Is that tradeoff worth it at this time? I’d argue “no”, but that’s only an opinion.

     

    Again, we all want Alfred to be better. And we all want Alfred to be as powerful as it can be as long as it doesn’t come at the expense of speed or stability. But every change you make has multiple costs; considering those before investing is wise.

  2. Welcome @Strayer,

     

    22 hours ago, Strayer said:

    Alfred will act on the first ctrl down/up and open the "sub menu" for the first found search result.

     

    Please be more specific. Possibly with a screenshot. I had a few ideas but from what I see in the preferences, none of them use the Ctrl key. Without knowing exactly what’s happening, it’s hard to say how to disable it.

  3. 15 hours ago, godbout said:

    OneUpdater i had a look a few weeks ago and actually added it in Kat 6.0.0 but removed it in 6.0.1, i didn't like that it was breaking my flow when i wanted to use the Workflow and just launched the update.

     

    You didn’t ask, so I didn’t know you were having an issue. That sounds like you were using the wrong option in the wrong place. You should add the Run Script version at the end of the Workflow. That’s the proper way for it to only check for updates after your action is done.


    Alternatively, just deleting the open "${HOME}/Downloads/${alfred_workflow_name}.alfredworkflow" line near the end will make it do everything as usual, but it won’t open the Workflow itself. Meaning the user gets a notification that a new version was downloaded but has to manually open it from ~/Downloads at a later time.

  4. If you’ve been sent here, you asked a variation of the question in the title.


    Depending on your needs, you may get by with @deanishe’s Firefox Assistant, which works via a custom browser extension. If your requirements are more complex than that, the answer becomes “you can’t do it”. Not without convoluted GUI automation—unreliable and error prone—or building your own complicated solution.


    If you need your automation more than you like Firefox as your daily driver, your best bet is to switch. Firefox is the sole major browser on macOS that’s incapable of meaningful automation through AppleScript (most other browsers get it for free from the Chromium engine), and the bug report for it is two decades old. Via different conversations with Firefox representatives I’ve (anecdotally) come to the conclusion that despite a large portion of their developers using macOS, they neither understand what AppleScript is nor that you don’t need to be a power user to benefit from it. In other words, improvements are unlikely to come soon.

  5. I’ve been asked in another setting if I have any plans to compile the PinPlus app for Apple Silicon. Decided to answer here because private questions take a long time to reply to and don’t benefit other people.


    At present I haven’t decided if that’s going to happen. While I’m on Apple Silicon and originally built the app for myself, I’ve been getting by with the other feature of the Workflow (which opens a new browser windows instead of using the app).

     

    Compiling for Apple Silicon will require updating dependencies, then dealing with whatever that breaks (likely a lot, in true Electron and JS fashion), and at this point the app would already need other fixes. Working on it is becoming hard to justify because:

     

    • It takes a ton of effort to maintain. I need to keep up with things outside of my control.
    • Working on it gets me no benefits, monetary or otherwise.
    • Working on it has drawbacks, in the form of more (unpaid) work and less free time.
    • I have no idea how many people rely on it or like it, since I use no analytics.
    • It isn’t necessary for the Workflow to do its job.
    • I’m no longer using it (partly due to the above).


    So that’s a tough sell. If you really like the app and would like to keep it alive, we can talk and perhaps figure something out. If, however, like me you could take it or leave it by now, the likelier outcome is that I’ll eventually discontinue it. You’ll continue to be free to use it until it breaks for you (due to an OS upgrade or the like), naturally.


    I want to make clear all of the above refer to the app; the Workflow itself is still going strong and will keep being supported and improved for the foreseeable future. I use it daily.

  6. Welcome to the forums,
     

    I have toned down the original title, as both it and the top of your post punch down on other Workflow developers who also worked hard on their converters. The Alfred forums aim to foster a respectful community where we try to support each other and have everyone’s Workflows be better.

     

    The “best” workflows are subjective. The power of Alfred lies in everyone being able to decide on their own tradeoffs. By requiring users get an API key, your Workflow is already disqualified for plenty of people.

     

    While it’s fine to ask for donations, that in conjunction with the rest of the post and title made it look like spam. We don’t know you yet and can’t even trust you’ll stick around and fix bugs in your work (almost no one makes a living on open-source donations, and none of those are making Workflows). Please get to know the community (and let us know you) before making definite claims.

  7. 2 hours ago, leonseled said:

    Thought it was just a syntax issue so screenshot of how I wrote it would've sufficed.

     

    In this case yes, but only because I wrote the code you copied and I’ve put a lot of work into understanding these AppleScript browser differences. The issue is that Chrome doesn’t understand documents[0]; it would have needed to be windows[0].activeTab. But even I had to look that up from my notes, because Safari has the similar windows[0].currentTab and those aren’t interchangeable.

  8. 1 hour ago, mookee said:

     

    The comments are turning it in an unproductive direction. You shouldn’t have mentioned Alfred at all, because that’s absolutely irrelevant to the equation and will only complicate things. To be efficient, Stack Overflow questions should distill the problem to their core. Alfred can run whatever is run in a shell so what you care about is if there’s any tool which will allow you to interact with an Apple Remote from the command-line. If there is, it can be called from Alfred; if there isn’t, it can’t.

  9. In Post Notification, Title says: “The passed-in {query} will be shown”. However, this is not always the case.


    When both Title and Text are empty, it does work: the passed-in query shows as the title. But if Title is empty and Text isn’t, no title is shown. However, if one sets Title to {query}, it works again.


    That almost looks deliberate, but I’m guessing it isn’t. Especially since “The passed-in {query} will be shown” still shows in the case where it doesn’t show. Here’s a reproduction Workflow.

     

    sVAJxta.png

×
×
  • Create New...