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

jbmanos

Members
  • Posts

    8
  • Joined

  • Last visited

Recent Profile Visitors

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

  1. Devonthink has always had awesome app suites for OSA land. You’re quite mistaken. same with being mistaken about Pixelmator pro. It’s a macOS app and has several extensive OSA suites. shortcuts may be nice but if they will ever be anything, they will tie into the OSA also.
  2. I only say what Steve Jobs said of it when describing the NS architecture. The same description is repeated in the OSA release and by the apple automation guys since I can remember all the way back to system 7 and 8. if this were an MVC, the concept is literally that OSA is an alternate to the VC of the UI. That’s how it’s supposed to be viewed and implemented through the SDEF. It’s scary that Adobe is a better player here than Apple itself. it’s not dead - applescript 2 has been a dead man walking for 20+ years now. JXA is more dead than applescript - it was faintly released, had a bunch of promise but it gets less discussion than Applescript (!). Perhaps the biggest reason is the ASobjC opens the entire NS foundation and OS and added frameworks to it. Shortcuts, as they are now, are nowhere near what OSA is This is why I bring it up, however - power users may be few - probably less than .1%, but people who use it - like me - become evangelists for apps that are fully baked (Devonthink and Adobe are great examples - and surprisingly Pixelmator Pro - you know, the affinity competitor from an even smaller shop than Serif). I know more than one shop that stays on Adobe because their shop automation more than pays for the enterprise licensing. And what’s best for them is that half their office can write, maintain, and improve their own automation objects because applescript is so easy. for instance, chugging an invoice for a client through their InDesign happens without anyone opening excel, FileMaker, or indesign itself Same with sending a comp sheet to a client - click a droplet, select client and project from a list and everything happens in a predictable, same quality every time, polished way… Meanwhile, as I said above - scripting within the app is another no brainer - but let’s not poo poo Applescript without understanding just what it is and how commercially valuable it actually can be - even a single designer shop could do the work of an agency with simple automation that’s easy to understand and maintain. That’s what applescript does. That’s also why I know several designers that like affinity but can’t justify switching because it would wreck how easy the workflows have made the admin side of design agency.
  3. That’s missing the point also. When I started the reply here, I was trying to explain that applescript is not the same thing as what people are asking for when saying “scripting” I understand what you guys want is a way to - only as a means to give example here - program macros WITHIN the program. Let’s call that scripting. Adobe uses JavaScript for this, MS uses Visual basic, etc. As @walt.farrellsaid above - this sense of scripting IS cross-platform. I agree with what he said in this context and for that use of scripting (ie within the program) What I poorly explained above is that AppleScript dictionaries are a fundamental of macOS apps and Affinity has not provided even a basic dictionary for any of its apps. Applescript is not scripting as the term is being used here. in other words, let’s say tomorrow that Affinity adds scripting and it is everything @walt.farrell wants. I’d be happy because we all can share programmatic macros and what not and those would likely not be platform dependent. But there would still be a deficiency on the macOS apps - my complaint that the apps are half-baked would remain. we really are talking about two different things here.
  4. This is funny -- did you mean to intentionally shift the focus here? Adobe and Microsoft finish their macOS apps and have fully functional AppleScript dictionaries. Affinity so far has not and consequently has half-baked macOS apps. I think you just don't understand what this is.
  5. Please explain how Adobe and Microsoft do it. I've given the explanation but you seem to have a concept of this macOS functionality that is not accurate. What you are saying means that you don't think macOS apps should be fully native because your operating system lacks similar capacity. Again, Microsoft and Adobe do it -- Adobe does it very well, in fact.
  6. That's funny. I think you mean WINDOWS needs to have an exposed object model. AppleScript dictionaries are a basic feature of mac apps. It's a shame that the Affinity apps are half-baked on macOS because this basic feature has been omitted. It prevents the apps from being used in automation on macOS. Adobe does it and they are cross-platform. Same with any other number of cross-platform apps, including Microsoft Office. The Adobe dictionaries are fully featured, and complete -- in may ways, even better than Apple does with its own apps, in fact. So it's difficult to see how you arrive at this conclusion, unless perhaps you misunderstand what is being asked for here.
  7. There is a lot of misunderstanding here. In order to allow *any* language to access the object model (properties, functions, data, etc...) of the affinity apps, they have to define an AppleScript (SDEF) dictionary for the app and methods. The truth is that Serif has already made the object model for all the apps, but they have not typed the descriptions into the SDEF portion that winds up forming the scripting dictionary for the macOS environment. I'm especially tickled at the people above that think that javascript will make it cross-platform -- totally irrelevant. On macOS, any number of scripting language could be used so long as that language has a scripting bridge, and as long as the app has exposed its object model to apple events through defining the AppleScript dictionary.. What this means practically, is that once Affinity fills in the AppleScript dictionary, then not only AppleScript, but all these other languages, such as JXA, swift, obj-C, browser javascript, python, etc, can access the app and data model therein. If I understand correctly, this is sort of like what MS is trying to do with powershell. But, I have not used powershell and really don't know how it works on Windows. What I do know is that the Adobe apps have AppleScript dictionaries, as do Pixelmator PRO and Acorn, so whenever I want to batch process images or whatever, I can use applescript, JXA, or any other language to have those apps do work on the images, but Affinity cannot, sadly. So if I want to automate checking minimum line widths in a large doc in order to be sure I've met printer specs, I can run an AppleScript, or javascript, or whatever -- in any of those apps with AppleScript dictionaries -- which excludes affinity at this point.
×
×
  • 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.