Jump to content
You must now use your email address to sign in [click for more info] ×

Search the Community

Showing results for tags 'cli'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Affinity Support
    • News and Information
    • Frequently Asked Questions
    • Affinity Support & Questions
    • Feedback & Suggestions
  • Learn and Share
    • Tutorials (Staff and Customer Created Tutorials)
    • Share your work
    • Resources
  • Bug Reporting
    • V2 Bugs found on macOS
    • V2 Bugs found on Windows
    • V2 Bugs found on iPad
    • Reports of Bugs in Affinity Version 1 applications
  • Beta Software Forums
    • 2.4 New Features and Improvements
    • Other New Bugs and Issues in the Betas
    • Beta Software Program Members Area
    • [ARCHIVE] Reports from earlier Affinity betas

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Location


Interests


Member Title

Found 3 results

  1. The following thinapp.py Python 3 script can be used on macOS systems to thin the multi-architecture Affinity apps (the FAT binaries, containing "x86_64" and "arm64" architectures) to the one only specific architecture just required by the particular Mac platform ("x86_64" or "arm64"). This will reclaim some disk space. Important prerequisites in order to make use of the thinapp.py Python script: Python 3 is installed on your MacOS system MacOS lipo from the Xcode development CLI tools is installed and can be find under /usr/bin/lipo ...or... an alternative GO based lipo from https://github.com/konoui/lipo/ A working file command is available and can be find under /usr/bin/file In order to check for the needed prerequisites, you can perform a corresponding which command execution in Terminal.app: > which python3 /Library/Frameworks/Python.framework/Versions/3.10/bin/python3 > which lipo /usr/bin/lipo > which file /usr/bin/file If all of the above prerequisites are met, you can execute the thinapp.py Python 3 script in Terminal.app like this to get a short help overview... If you apply execution rights to the thinapp.py Python 3 script, via "chmod +x thinapp.py" in Terminal.app, then you can also execute the script via it's filename directly just by calling it, aka thinapp.py or thinapp.py -h . For the -arch option argument supported architectures are x86_64 or arm64, in order to thin an app to an just Intel or Arm platform specific app only here! Now in order to thin let's say Affinity Designer.app to contain just the Intel "x86_64" architecture and thus to strip out the "arm64" architecture from it's FAT binary app, you would call thinapp.py this way ... ... which in turn would then create a duplicate copy of "Affinity Designer.app" under the by the -o option as argument given file path "/Users/<yourusername>/tmp" and then process to thin it there under the "/Users/<yourusername>/tmp/Affinity Designer.app" file path. The as -arch option given x86_64 argument tells thinapp.py to keep just that x86_64 architecture, meaning that the arm64 architecture will be stripped out of the FAT binary app. After the script has finished it's work, you can compare the ADe sizes under "/Applications/Affinity Designer.app" and "/Users/<yourusername>/tmp/Affinity Designer.app" in order to see how much space has been reclaimed due to the architecture thinning process. Next you can start the thinned app from "/Users/<yourusername>/tmp/Affinity Designer.app" in order to see if it operates well. - If all is fine, you can remove the initial "/Applications/Affinity Designer.app" and replace it with the thinned one from "/Users/<yourusername>/tmp/Affinity Designer.app" (... so exchanging the initial with the thinned app). What you can expect from thinning the V1 apps of ADe, APh and APub size wise is ... ADe v1 = initially ~2.59 GB after thinning to x86_64 it has then ~1.69 GB APh v1 = initially ~2.65 GB after thinning to x86_64 it has then ~1.71 GB APub v1 = initially ~2.60 GB after thinning to x86_64 it has then ~1.65 GB Here's the thinapp.py Python 3 script: thinapp.py <-- has been updated! And as always, have fun!
  2. I'm a web dev & photographer. Affinity Photo's 1.) automatic masking to remove white backgrounds, and 2.) "Erase White Paper", are INCREDIBLE! They work PERFECTLY, including inside holes in a product. Much better than I've seen elsewhere. But it is extremely tedious work to do this manually for all photos. I'd love to automate Erase White Paper at the server level (like we do for resize & trim currently)--to enforce consistency for ALL our images. Then Affinity is used for creative tasks. Feature request: I'd LOVE to see Affinity create an open source tool on Github for 'Erase White Paper'! Or to contribute it to libvps, which is used by Sharp. It would win HUGE goodwill among the open source community to see this contributed by Affinity--because it's not something Adobe would do--& it's a key thing missing from Sharp. Thanks!
  3. So I've run into a conundrum - the Affinity suite of apps that I purchased from the Microsoft Store doesn't appear to have command-line support. This is because those Windows Apps downloaded from the store are sandboxed off away from users. You cannot directly find the `Photo.exe` file from the Explorer (unless you're willing to blow away a lot of permissions). The best I could find on how to start Affinity Photo from the MS Store from the command line is the following: powershell.exe explorer.exe shell:AppsFolder\$(get-appxpackage -name SerifEuropeLtd.AffinityPhoto ^| select -expandproperty PackageFamilyName)!SerifEuropeLtd.AffinityPhoto But that doesn't allow me to pass in any arguments into the Photo executable. There does appear to be a solution though. First - the Affinity Suite of apps could use Command Line Activation. That would basically set up an alias so that users of the command line could send arguments to that exec alias. The apps would just need to update their OnActivated handlers for the new CommandLineLaunch activation kind. Another option could be to create and register a Protocol. This is similar to the Command Line Activation, but now you can have the Affinity apps open based on URL. For example, afphoto:// could open up Photo, and afphoto://file=foo.tif could open load the foo.tif file into Photo. Maybe you could even supply actions to Merge or create HDR from URL parameters - but that would just be icing on the cake. If your curious about my reasoning (like, who really needs to use the command line for this!?!?), it's that the UWP MS Store app boundaries are preventing integration with my DAM. I use Capture One, and C1 cannot find Affinity Photo because I cannot navigate to the app from the Windows Explorer (files and packages are hidden). By having these entry points, it could allow for me to create an extension to Capture One or a batch command wrapper so that I can send the files I want to edit over to Photo. To be clear, if I had purchases Photo directly from Serif, this wouldn't be an issue since the app gets installed in Program Files and I can browse for that. Thanks for your consideration. I hope the links show that to enable the feature wouldn't require too much code to get that done (well, how could I really know, I haven't seen your code) and would love to see that. I thought purchasing the MS Store version would just mean the apps would behave the same and that I wouldn't have to worry about performing updates manually - but now I know a little more about how UWP apps work and sorta regret doing so. Cheers and all the best
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.