Jump to content

xilopaint

Member
  • Posts

    894
  • Joined

  • Last visited

  • Days Won

    24

Everything posted by xilopaint

  1. What are some real life use cases for this app? I've installed it in the past but never ended up using it.
  2. Notificator integration to the library is done. It's really straightforward and alfredish. Thanks, Vítor!
  3. You're fine with both Python installations. It won't break your Python 3 workflows but some Python 2 workflows will still need a tweak to work.
  4. What every user expects is to have their workflow updated with the latest version and not two different versions with one of them broken. Btw it’s not only a matter of confusion. You changed the bundle id of the workflow with your own name and it’s not clear to me if the real owner was aware of this change. It’s not easy to spot this kind of change on the info.plist before the pull request is approved. I can’t know the opinion of the owner, but it’s definitely not cool.
  5. Why did you change the bundle id using your name in a workflow whose maintainer is not you? Btw I didn’t know the change was related to this topic when I created this issue on the GitHub repo.
  6. Great! I hope to have some time to work on it during the weekend. I can add the note on the top description of the notify module . Regarding the creation of the library repository I’ll wait for @deanishe decision about the library’s future so he can tell us if there are plans to an official update or the community should carry on.
  7. If I understood it correctly, Alfred PDF Tools covers this workflow features in a more efficient way. I'm just waiting for your decision about Notificator to release a new Python 3 version of the workflow.
  8. It would be great. I just tried to point out that PyObjC would not be required in a possible integration of Notificator even in its current implementation. My main issue with Alfred-Workflow is the need of PyObjC. If I embedded the library with a minimal part of PyObjC needed to the job it would still add 4.8MB to the library. Not a great choice. In any case I'm gonna wait for your decision about a new implementation for Notificator.
  9. Notificator needs to be built in advance, for the icon. Though I could change it so it’s built on-demand and cached. I’ll have a thought about that. This is not different from Alfred-Workflow. If the user invokes the notify function to fire a notification it first checks for the presence of Notify.app in the data folder. If Notify.app is not present the install_notifier function is invoked and Notify.app is extracted from the library folder and moved to data folder where the icon is changed and the bundle id set. def install_notifier(): """Extract ``Notify.app`` from the workflow to data directory. Changes the bundle ID of the installed app and gives it the workflow's icon. """ archive = os.path.join(os.path.dirname(__file__), 'Notify.tgz') destdir = wf().datadir app_path = os.path.join(destdir, 'Notify.app') n = notifier_program() log().debug('installing Notify.app to %r ...', destdir) # z = zipfile.ZipFile(archive, 'r') # z.extractall(destdir) tgz = tarfile.open(archive, 'r:gz') tgz.extractall(destdir) if not os.path.exists(n): # pragma: nocover raise RuntimeError('Notify.app could not be installed in ' + destdir) # Replace applet icon icon = notifier_icon_path() workflow_icon = wf().workflowfile('icon.png') if os.path.exists(icon): os.unlink(icon) png_to_icns(workflow_icon, icon) # Set file icon # PyObjC isn't available for 2.6, so this is 2.7 only. Actually, # none of this code will "work" on pre-10.8 systems. Let it run # until I figure out a better way of excluding this module # from coverage in py2.6. if sys.version_info >= (2, 7): # pragma: no cover from AppKit import NSWorkspace, NSImage ws = NSWorkspace.sharedWorkspace() img = NSImage.alloc().init() img.initWithContentsOfFile_(icon) ws.setIcon_forFile_options_(img, app_path, 0) # Change bundle ID of installed app ip_path = os.path.join(app_path, 'Contents/Info.plist') bundle_id = '{0}.{1}'.format(wf().bundleid, uuid.uuid4().hex) data = plistlib.readPlist(ip_path) log().debug('changing bundle ID to %r', bundle_id) data['CFBundleIdentifier'] = bundle_id plistlib.writePlist(data, ip_path)
  10. I got over this issue and the workflow will work with Developer Tools. I can offer v3 beta builds to some people willing to give me feedback through Telegram. Who's up? @evanfuchs @TheThunderChimp
  11. Hey @vitor, I’m finishing the work with Alfredeanishe (the name I gave to the community port of Alfred Workflow in honor of our hero 😄). Alfred-Workflow library has a class named Workflow and its instance (the Workflow object) is the main interface to the library, which “provides APIs for accessing the Alfred/workflow environment, storing & caching data, using Keychain, and generating Script Filter feedback” according the docs. The point is the Workflow object "is targeted at Alfred 2" and Workflow3, a subclass of Workflow, should be used for Alfred 3+ features. This choice was understandable for some time but I think now we should drop Alfred 2 support and moving forward. That’s what I did removing the Workflow3 module and putting everything together. It makes the codebase way cleaner. I still can’t be sure I haven’t committed some mistake but in my tests everything seems to be working fine. One of the last issues I’m still facing is regarding the notify module. As you can see in the original code an AppKit module should be imported but it’s not part of Python standard library but part of the PyObjC bridge. I suspect PyObjC was embedded with Python 2 in macOS versions earlier than 12.3 (unfortunately I can’t check this on my up-to-date macOS). This StackOverflow answer mentions a /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC path (was that installed by default?). Well, at this moment I’m searching for the best solution for this issue but first of all I would like to be sure it’s not only a problem on my machine and AppKit cannot really be imported through Python in macOS 12.3. If it's the case, one solution would be embedding the Library with some PyObjC modules and other solution would be using something like Notificator.
  12. No contribution to this transition would be better than a solid ported version of the Alfred-Workflow library. Not only a dirty version that "works" but something with good, clean and maintainable code. It would speed up a lot the porting of the Python workflows. But I would still wait for @deanisheto say about his plans on the future of the library before starting (or not) a community version of the library. Btw, I have my own altered version of the Alfred-Workflow library. Not perfect but still cleaner in some aspects than the forked version some devs are using.
  13. Well, I’m starting with my own Alfred PDF Tools workflow. As the work gets stable enough to be released, which is not trivial since I adopted a new library for PDF manipulation, I will start to make transitions of workflows that I used to use. A lot of Python workflows take advantage from the non-Py3 compatible Alfred-Workflow library, which is why so many workflows still use Python 2 despite of the language constrains.
  14. Maybe @deanishe has a say here? The issue is really weird. If I install pikepdf using pip install pikepdf -t . I get an import error with Python 3.8.9 and Python 3.9.10, although Python 3.10.2 works good. On the other hand I don’t get any error if I don’t use the -t flag at all to install the package. Obviously I’m using the flag because I want to embed the workflow with the package.
  15. Sorry for the late response. I have fully rewritten this workflow using Python 3 and pikepdf (a more modern library than Pypdf). Your files work perfectly in this new unreleased version. The problem is I can't release it until the system Python gets upgraded to 3.10 which can take a long time. I don't know why pikepdf cannot be imported by Python 3.8 and 3.9. If someone gives me some light on what changed on Python 3.10 about imports maybe I can release the new version before the upgrade.
  16. I agree. But that takes time. And we also have to think of the non-coders who find themselves with broken tools and need a workaround. This solution is a stop-gap, not the end goal. See my other comment for a more complete answer. I've always been curious about the percentage of non-coders in Alfred's Powerpack user base.
  17. I really think the community should put some effort to update our workflows and add support to Python 3. I refuse to install Python 2 on my machine as of Monterey 12.3.
  18. Hey @RodgerWW, I'm working on an update to the workflow for supporting Apple M1 Chip but I need an icon. Where did you get the icons for the graphics? Did you find it somewhere in the system?
  19. It looks great! Thanks a lot, man!
  20. I don't need CN and have no idea how much work it would get for all of them. USD-M Futures is what I'm working on at the moment so it would be fine. Btw is the fine-tuning something I could make by myself after you create the docset? Is there a file that I could edit to improve the sections of the docs and make it better for the search on Dash?
  21. Yes, I would like! I'm working with that API at the moment. Also, I would appreciate if you could ELI5 (step by step) how I can use the builder to generate docsets and fine tuning after that. Do I need to know PHP for it?
  22. The User Manual is useful, but not as useful as the Language Reference Manual. I don't want to waste your time. I asked that assuming your builder could make it easy. Thanks anyway! Yesterday I managed to create my first docset from a Sphinx based doc using doc2dash. It's great! Btw, do you know some tool that could be used to convert this documentation in a dash docset?
  23. Hey, I suggest you to use OneUpdater to add auto-update capability to Alfred Kat. It's very easy to implement.
  24. Thanks!!! I think only for different posts.
×
×
  • Create New...